Re: Some Performance Tests

On 2007-02-24 at 20:49:12 [+0100], Axel Dörfler <[email protected]> 
wrote:
> Ingo Weinhold <bonefish-CFLBMwTPW48UNGrzBIF7/[email protected]> wrote:
> > I'm moving the thread to this list (is the OBFS list still in
> > existence?
> > sending a mail to it bounced and it isn't listed on the website) to
> > not
> > bother the admins not interested in this technical issue anymore.
> > I've
> > inserted the results for the Create/Delete test for the same BFS
> > partition,
> > just initialized *with* indices. The drop in performance is worrisome
> > IMHO.
> > The Raw Write and Find results are, as expected, virtually identical,
> > so I
> > left them out.
> 
> More than twice as slow is certainly a bummer. One thing that would be
> interesting to know is how often the file systems sync the HD caches.
> Does your ReiserFS uses the BeOS cache?

No, I implemented a simple own block cache after the BeOS block cache showed 
dramatical memory usage in my first tests -- I first though it leaked memory, 
but it just seemed to use a lot, unlike for BFS volumes (probably related to 
the greater block size). Anyway, performance-wise there was no measurable 
difference between the cache implementations, IIRC.

> BTW if I recall correctly, all speed comparisons in the BFS book were
> done without indices.
> 
> > For Haiku/OBFS the Create/Delete test hits KDL, unfortunately. I hope
> > this
> > will be fixed in the not too distant future, since I'm quite
> > interested to
> > see how Haiku fares.
> 
> You could just lower the amount of data copied, that should help for
> now :-)

Yep, will do that. If you have more tests you'd find of interest, tell me 
(ideally in runnable shell command lines :-)). I'll probably try src/bin/gdb, 
which should weigh in with 60+ MB, hopefully small enough for Haiku to 
survive, while at the same time hopefully big enough for being interesting.

> > du adds it up to 332243 KB (only 325750 KB on the ReiserFS partition,
> > thanks to many directories, I suppose).
> 
> That might hit some limit with "only" 512 MB. But it could also be a
> different bug than the Luposian copy bug - since the kernel should
> already be smart enough to remove files that aren't in use anymore.

If you want more info, tell me. But I suppose you could just run something 
like this yourself. :-)

CU, Ingo

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV