Closed nicktacular closed 4 years ago
This is because dateparser reads the language configuration files at import time, that's why it takes a little while to load. However, this only happens the first time you import it.
Why is this a concern for you?
@eliasdorneles it's a concern because any Python script which runs frequently now runs at least 0.5 seconds slower. If the script is expected to react quickly due to doing something simple, waiting a 0.5 sec longer seems odd.
Is there a way to specify not to load any language configs that I won't be using? I'm only interested in parsing dates in English.
@nicktacular it's a valid concern and can be resolved by a combination of lazy and on-demand loading of languages data.
Is there a way to specify not to load any language configs that I won't be using? I'm only interested in parsing dates in English.
This will be possible after we implement said idea. Will push a fix soon.
Excellent, thank you.
Any updates on this? I'd love for this to be faster.
@waqasshabbir I would love to work on this issue. I am a newbie so please guide me to fix this issue.
For version 0.7.0 import time went down to less than 0.20 s. Is that within acceptable boundaries, @nicktacular?
@asadurski cool, I will try using this again.
Shall we close this?
I vote to close the issue, yes, as I don't see a strong need to improving this much given that it happens only once at import time.
Users who only need basic English date parsing and want to improve the performance can use dateutil.parser.parse
directly.
We've replicated this on both OS X and Ubuntu 16.04. Importing takes around 0.5 - 0.7 seconds to import. It's unclear what the cause of this is but is a significant performance concern.
OS X
Ubuntu 16.04