You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Calling into the AnalysisManager to get lookup pixel colors is significantly slower (across the loop's course) than the previous method which had a direct lookup of a color table which was local to SolveInstance(). Ideas for improving performance here while keeping the abstractions from the analysis classes:
Extracting the relevant lookup tables into a local variable before entering the loop
Setting the relevant GetPixelColor for each analysis type as a delegate method before entering the loop
I'm not very clear as to the relative low-level performance differences between different options here so will play around and see what works best. As we are dealing with pretty small differences in time I might try and make some mock functions that can simulate the process of coloring the per-pixel loop in a way that can be more easily run multiple times and averaged. I had a go at using benchmark do net for this, but didn't have any luck integrating it as either a console app (which then couldn't call into rhino common) or as a separate plugin (which then couldn't instrument methods within SolveInstance). Maybe the dotTrace profiler will help.
The text was updated successfully, but these errors were encountered:
…losesmariuszhermansdorfer#29
This includes earlier optimisations that were not present (e.g. the color table as a dictionary) and reworks the way analysis is applied so that mariuszhermansdorfer#33 can be implemented. Future tweaks will be benchmarked and sent in PRs
Calling into the
AnalysisManager
to get lookup pixel colors is significantly slower (across the loop's course) than the previous method which had a direct lookup of a color table which was local toSolveInstance()
. Ideas for improving performance here while keeping the abstractions from the analysis classes:GetPixelColor
for each analysis type as a delegate method before entering the loopI'm not very clear as to the relative low-level performance differences between different options here so will play around and see what works best. As we are dealing with pretty small differences in time I might try and make some mock functions that can simulate the process of coloring the per-pixel loop in a way that can be more easily run multiple times and averaged. I had a go at using benchmark do net for this, but didn't have any luck integrating it as either a console app (which then couldn't call into rhino common) or as a separate plugin (which then couldn't instrument methods within
SolveInstance
). Maybe the dotTrace profiler will help.The text was updated successfully, but these errors were encountered: