[haiku] Re: GSoC 2009
- From: Bruno Albuquerque <bga@xxxxxxxxxxxxx>
- To: haiku@xxxxxxxxxxxxx
- Date: Tue, 20 Jan 2009 09:31:07 -0200
Ingo Weinhold wrote:
This heavily depends on the FS you're using in Linux, though.
ext3. That misses the point tough. ext3 always kicked the original BFS
under BeOS performance-wise when doing tests with small files. In Haiku,
as I mentioned, they are almost the same when data has to be read from
disk (that could be because I have a very fast machine tough, so raw HD
speed is the bottleneck here). Thatś a huge improvement even if this is
just a synthetic test.
The last time I tested ReiserFS 3.6 totally beat the heck out of BFS.
Well, even if we could get OpenBFS on par with ReiserFS
performance-wise, we would still need to get Axel to kill someone. ;)
The comparison between Linux and Haiku is not very fair, since Linux
> is generally more optimized and faster, but one can do the test in
> Haiku (at least an "svn stat").
Another point that must be considered is that under BeOS svn had to use
hacks for file locking. That also had its performance impact.
In any case, the fact that Linux is a lot more optimized (and I
mentioned this) makes the current results even more impressive when
compared to results from the original BFS.
IIRC, the measurements indicated ReiserFS to be almost twice as
fast as BFS.
Maybe it just improved now? :)
Interestingly the results of a second (i.e. cached) run were very much in
favor for BFS. Might be file vs. block cache related or our BFS
implementation is just faster than that of ReiserFS.
You know, I am highly suspicious that the "complete system freeze"
during IO is actually related to memory allocation and not to disk IO
itself. I don't have any tangible evidence for that yet, but I did a
simply tests with dd in=/dev/some/hd/partition of=/dev/null bs=128k and,
as I remember it, I did not get the freezes. It was a while ago tough so
I will test this again when I am back at home and report on the results.
-Bruno
Other related posts:
