#2 Working, but incredibly slow

open
Brad Boyer
None
5
2002-08-19
2002-08-19
Anonymous
No

It seems to work fine, and I can read data from files,
but at an unusably slow rate. Less than 1MB files take
in the order of half a minute to fully read.

Any ideas?

Discussion

  • Brad Boyer
    Brad Boyer
    2002-08-19

    Logged In: YES
    user_id=73195

    Yes, it's slow. It probably won't get fixed until the next
    major rewrite. The problems causing this are pretty deep in
    the code, and at this point, correctness is more important
    than speed.

     
  • Brad Boyer
    Brad Boyer
    2002-08-19

    • assigned_to: nobody --> bboyer
     
  • Logged In: NO

    Couldn't just make it a little faster? Anything is better
    than the speed I'm currently getting.. I'm using it for an
    embedded automated software license scan, which basically
    goes through every file on each partition and I think to do
    one machine would take more than a day, which is far too long :<

    Anyhow, thanks for the good work on this project. HFS+
    support has been needed for a long time.

     
  • Logged In: YES
    user_id=382485

    I am experiencing similar slowdowns, on a RH 7.3 box,
    regardless of partition. Directory access ie. filenames seem
    to be fine, but data transfer is really slow. But everything
    seems to work otherwise.

     
  • Logged In: YES
    user_id=130268

    I noticed that too, but only if the hard drive(s) are
    otherwise idle. So when I
    have to, I just run "find /" in the background, and the
    speed becomes quite correct while it is physically reading
    sth from the disk.

    No idea what might be causing this, though.

     
  • Logged In: YES
    user_id=382485

    Hmmm, perhaps I'm wrong, but that sounds like we're busy waiting or
    something, ie. not getting requests filled unless there's other activity. Is
    the module working with the disk cache correctly or is there some way in
    which it should be listening for wakeups/completion notification?

    Just wondering,

    TJ

     
  • Logged In: YES
    user_id=382485

    Well instead of speculating I decided to do some, admittedly
    unscientific, stopwatch tests.

    On my test box (RH 7.3, PII/350, etc.) using "cp src dst";

    A 31 MB sit file takes ~ 15 sec to xfer from a HFS+ vol to a EXT2 vol.
    The same sit file takes ~ 3 sec to xfer from a EXT2 vol to a diff EXT2 vol.
    (I've tried to take into account caches etc. so the numbers are after a
    fresh boot or mount of the volume.)

    Additionally trying to do the copy(from HFS+ to EXT2) after having copied
    it once already, is only a few ~2-3 sec so it seems that the block cache
    is working fine with the HFS+ module.

    So HFS+ read access is roughly 4 times slower than EXT2 right now, at
    least on my machine given the way that I've tested it, which given all the
    work that has gone into getting EXT2 fast, that shouldn't be that
    surprising.

    Although it's been a while since I poked that deep into the MacOS,
    wasn't it keeping an extent cache associated with the FCB's?
    I believe that the FCBExtRec kept the first few extents, was this also
    true for HFS+?
    And there was also the BTree cache as well, so is it possible that part of
    the difference is extent lookup overhead and conversion to Inodes?