> > Yeah, you really need to be careful about methodology here. > > If you want to select typical things and get typical response times, > you probably need to carefully think out the typical things people do > at the user interface and mimic them in the CLI and run them on many > different configurations. > > I doubt many people list the top thousand songs when they're at the > remote. > > If you want to benchmark the code to do before and after studies of > code improvements, you need to have one typical machine, benchmark it > accurately AND THEN FREEZE IT AND DON'T CHANGE IT. That almost means > dedicate it to the benchmarking task and making it a reference system, > because you never know when installing Microsoft Office 2007 (heaven > help us) or IE 17.2 won't change the way I/O works or how much > background activity there is cluttering up the disk.
Note that I did not intend this to be a benchmark tool. In a lot of posts on this list people said the performance of their install was <insert your favourite speed indication here>, which was a very subjective indication. This program simply times a request to the CLI. It should give some idea about what a user would see if using a real SqueezeBox (assuming we use a reasonable set of CLI queries, which I probably don't). There are even some of us desparately switching OSes and tweaking stuff on the same machine and discussing whether ActiveState is faster than compiled Windows or CygWin or whatever. This tool then is able to give _some_ numbers. Again, you cannot compare them 1 on 1 to other installs, but IMHO if one install does someting in 20 seconds, and another one in just 2, there is going to be the same user experience when connecting and using a SqueezeBox. Niek. _______________________________________________ Discuss mailing list Discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
