Go to the FreeLists Home Page Home Signup Help Login
 



[openbeos] || [Date Prev] [02-2003 Date Index] [Date Next] || [Thread Prev] [02-2003 Thread Index] [Thread Next]

[openbeos] Re: testing enhancement

  • From: "Ingo Weinhold" <bonefish@xxxxxxxxxxxxxxx>
  • To: openbeos@xxxxxxxxxxxxx
  • Date: Thu, 20 Feb 2003 21:33:51 CET (+0100)
> right now, after the build finishes, since the OS isn't ready to be 
> used by itself, most testing is done using the unittester..
> when it comes to performance comparing we have the time it took.
> but this doesn't really show us if it's faster/slower than the 
> equivalent R5 implementation, or from recent implementations of the 
code.
> thus, i suggest the "score" would be kept somehow.
> a possible implementation would be a directory called speed
> it would have R5.txt obos[date].txt and obos[now-date].txt
> 
> then, when the unit tester measures the performance it can also 
> show if we're faster/slower.
> since it's command line, we can also dedicate a machine to doing a 
> test every X minutes and notify if there has been a slowdown.
> so the one in charge would be notified and think of an optimization.

While that is probably not too bad an idea in principle, I feel that it 
is still a bit early for general performance testing. Especially in our 
libopenbeos we have a couple of work-arounds that make objective 
measurement virtually impossible. I think, most of the stuff can't be 
thouroughly performance-tested before it runs on top of our own kernel. 
And for some classes, like BString and BList, tests have already been 
done.

CU, Ingo







[ Home | Signup | Help | Login | Archives | Lists ]

All trademarks and copyrights within the FreeLists archives are owned by their respective owners.
Everything else ©2007 Avenir Technologies, LLC.