-
Notifications
You must be signed in to change notification settings - Fork 8
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
[Enhancement] Timing for day construction #39
Comments
That kind of makes sense @tslater2006. |
Yea, i've gone back and forth on it which is why I didn't suggest a particular way :) The way I see it there are 3 choices
I think my preference is 1, 3, 2. I think 1 is easier in terms of making it optional? if people don't want that value to count then they can turn it off and just see what you see today. 3 is the only other "fair" way in terms of total runtime that I can think of. |
😆 fair enough. I'll give it a thought, create one/some PoCs and get back to you in the following days. |
Sounds good, thanks for being so open to feedback/enhancements :) |
The feature was relatively easy to implement, but now I'm struggling to make spectre.console cope with so many re-rendering with my own 2020's repo (🥳 that means that it's kinda performant haha). Meanwhile, you can test the functionality itself (and your constructors!) with this package and: |
* Add `SolverConfiguration.ShowConstructorElapsedTime` to allow measuring constructor time (closes #39). * Add `SolverConfiguration.ShowTotalElapsedTimePerDay` to aggregate constructor, part1 & part2 times (as it's done to calculate the mean time per day in the overall results panel). #43 is a known bug when using both options, but isn't caused by them.
I think it might be useful to (optionally?) allow to capture the timings of the day constructors. Day 7 of 2020, had a lot of up front processing that both parts leveraged. instead of doing it twice, it makes sense to put in the constructor. However doing so, the Part 1 and Part 2 become a lot slimmer just leveraging the data structures built by the constructor, and I think this results in artificially low runtimes, since the bulk of the processing wasn't accounted for.
The text was updated successfully, but these errors were encountered: