Timeline for What causes bad performance in consumer apps?
Current License: CC BY-SA 3.0
15 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| May 23, 2017 at 12:40 | history | edited | CommunityBot |
replaced http://stackoverflow.com/ with https://stackoverflow.com/
|
|
| Nov 7, 2013 at 17:18 | comment | added | Mike Dunlavey | @Crashworks: Also, my first-ever YouTube video, on random pausing, is here. | |
| Oct 2, 2012 at 18:50 | comment | added | Mike Dunlavey | @Crash: If you're still interested, here's probably the most math-heavy explanation I've put together. | |
| Sep 27, 2011 at 0:43 | comment | added | Steven Evers | @MikeDunlavey: Where I work, the doc people don't write the specs. Dev/QA does. | |
| Sep 26, 2011 at 20:26 | comment | added | Mike Dunlavey | @SnOrfus: I hesitate to agree because it's easy for a spec writer to way whatever comes into their head. At the same time I think debugging is about finding programs doing things for wrong reasons, and performance tuning is about finding programs doing things for poor reasons. Either way, it takes technical digging, not just measuring. | |
| Sep 26, 2011 at 16:47 | comment | added | Steven Evers | When the specs/requirements doc specify performance metrics... then bad performance is a bug. | |
| Jun 23, 2011 at 12:34 | comment | added | Mike Dunlavey | @delnan: I think we're in agreement. | |
| Jun 23, 2011 at 11:28 | comment | added | user7043 | @Mike: I'm not saying analyzing computational complexity is the way to go when hunting for a specific performance problem - of course, this is best done by looking at an actual run of the actual implementation. Quite the contrary, if you read again - I'm putting the former below the latter in the only sentence where I even touch it. | |
| Jun 22, 2011 at 16:41 | comment | added | Mike Dunlavey | @delnan: The first time I remember using random-pausing is around '78, on a Raytheon mini with "halt" and "step" panel buttons. I don't remember ever thinking there was any other way to do it. So, while big-O matters, it mystifies me how people can even discuss optimization in real software without first having the program itself tell them where to concentrate. | |
| Jun 22, 2011 at 14:28 | comment | added | user7043 | I agree in general. But despite misuse by people that don't even think about computational complexity, alone actual performance, sayings like "premature optimization is the root of all evil" (everyone who ever cites this should read the full version) and the 90/10 rule don't say "don't optimize" but "optimize efficently". Nobody gets anything from shaving a millisecond off initialization code; writing code with the intent to make every single line as performant as possible just leads to an unmaintainable mess that distracts from finding solving the relevant performance problems, etc. | |
| Jun 22, 2011 at 4:57 | comment | added | Crashworks | @Mike Sure, but later in the summer, I think -- I've got a huge backlog of articles and papers I already owe to GDC, #AltDevBlogADay, and my own employer! | |
| Jun 22, 2011 at 2:50 | comment | added | Mike Dunlavey | @Crashworks: That would be fun. If you're serious, drop me a line. | |
| Jun 22, 2011 at 2:48 | history | edited | Mike Dunlavey | CC BY-SA 3.0 |
added 9 characters in body
|
| Jun 22, 2011 at 2:44 | comment | added | Crashworks | Mike, one day you and I are going to have to write a book on sampled profiling together; it will be the "Cathedral and the Bazaar" of performance programming. | |
| Jun 22, 2011 at 2:41 | history | answered | Mike Dunlavey | CC BY-SA 3.0 |