GNOME Bugzilla – Bug 632269
Log slow commands
Last modified: 2011-04-22 19:58:08 UTC
Created attachment 172472 [details] [review] proposed patch Right now we don't log slow running commands as errors, doing so would increase the quality of bug reports and cut the requirement to ask users for separate --debug-sql logs. It would also make SQL related performance issues easier to spot quickly
I talked with david about this, and imho if there really is a significant amount of bugs or complains concerning banshee's performance this would probably the best way to nail the problem fast (and with the help of the users)
Review of attachment 172472 [details] [review]: Looks good, just update for style ::: Hyena.Data.Sqlite/Hyena.Data.Sqlite/HyenaSqliteCommand.cs @@ +62,3 @@ private object [] current_values; private int ticks; + const int threshold = 500; Fix capitalization and move to top of class private const int THRESHOLD = 500; private object result = null;
Created attachment 175249 [details] [review] updated patch Thank you for the review, there is the updated version with your requested changes for HACKING compliance.
Created attachment 175253 [details] [review] Once more with feeling And now it actually compiles
My only question is the threshold. Is 500 a good threshold for this? If it's too low we'll get slammed with bug reports saying banshee told them to file a bug, if it's too high it's ineffective.
I just picked a number for the sake of it. I think an good setting for this would be 100ms. Looking at what my modest dual core atom machine with a slow drive I see worst case times in debug-sql mode around 50-70ms in normal use. I think >100ms would be abnormal enough to both be felt as slow and not get triggered often in normal use.
Half a second is an absurd amount of time, however 100ms in experimentation on my machine seems to trigger to often for comfort. Perhaps we should put our foot down and say 250 ms. 1/4 of a second is certainly going to be felt and if we cannot fulfill that requirement on a modern machine are doing it wrong(tm)? It really depends on how we think this can be used best. If we are wanting to urge ourselves to do better I would say 250ms aiming to lower it with every major release cycle towards 100ms. If we are merely looking for the worst cases we should set this high, say 1000ms. I think perhaps the best way to go about this is to use a low setting for Active Development releases and a high setting for maintained releases.
I've started documenting all the common steps I am aware of for performance bugs. http://live.gnome.org/Banshee/CommonQuestions/PerformanceIssues In the process I experimented on a couple of machines and found that 1 full second seemed sufficient to not trigger this with disturbing frequency (which sounds like a lot in regular use depending on the task).
I committed a patch that, in --debug mode, will log cmds that take over 500 ms to run. This minimizes the risk of spewing tons of logging for lots of users, getting lots of bug reports etc.