-
Notifications
You must be signed in to change notification settings - Fork 68
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Performance improvements #49
Comments
Hey @yusufozturk Thanks for the contribution! Won't you want the You see, 5 years ago the code was slightly different and the field was needed, because it was called as first line in that method. And after several changes, right now it can be replaced with just a local variable and even removed at some point, as it's unused. So I'd be hesitant to make it part of API. But if you have wdyt? |
@goodsign that was my initial idea actually, but "Parse" method has "validateValue", so maybe using that is better? Also I didn't want to do too many changes, so I thought easier way would be extending the struct. |
@yusufozturk I see your point, but in this case I feel like we'd introduce some hacky API honestly, as the But I'm open to doing this slightly bigger / more properly. If we want a simpler solution and we anyway want to extend the API by one more public thing, maybe we can just do something like:
And as a bonus — delete the What do you think? |
The
|
Yes, they look good :) @goodsign |
Do you think you can publish a release today? I would like to update our project after that. |
I'd use some help with the PR/tests, actually 😆 As I'm not able at the moment, but I can review a PR with the approach above. |
Hi,
Thank you for this project.
I believe some API changes can increase the performance and resource usage. For example, a log file must contain same date layout. Instead of using "Parse" method for each date value, we can detect the locale only one time, and then we can call "ParseInLocation" directly to improve parse process. But right now, locale etc is private fields. So it's not exposed to us, and makes it impossible to change the logic.
If we can make the "LastLocale" field public. after first detection, we can get store the Locale and then call the "ParseInLocation" directly.
Thanks again.
The text was updated successfully, but these errors were encountered: