[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Sv: Sv: Strangest thing happened; ...
Bjarke Hammersholt Roune wrote:
>>>anyway at some point, why not just sort them at write-time instead of
>>>read-time? You just need to be ble to specify all the files that go in a
>>>format 1 when writing it at once for this to be effecient. You would still
>>Yup, right. But as soon as you add files the sorting is destroyed (it would
>>be of course possible to re-sort everything once a file is added, but
>>that's rather slow).
>When did adding one entry to a tree begin to require a complete resort?
not to a tree. The entries in Format 1 paks are stored as linked list. And
of course inserting the entry at the proper place is sufficient here, but
that's still a noticeable delay. Moving that to mounting time is better.
>>>to add and remove files while keeping the tree complete at all times (ok,
>>Do you have some code for this or can you describe in detail how
>>you're implementing a complete tree? I'm interested because you are right
>>in that point:
>Well... As it turned out, when I implemented it, the way I had figured out
>to add or remove entries DID put the entry you added in the right place, and
>DID remove the entry you wanted to get rid of, all the while keeping the
>tree complete at all times. However, the two techniques also displace other
>parts of the tree when the tree grows beyound a 7-8 entries.
>Strictly speaking, I actually do know how to do it, but that method is
>EXTREMELY ineffecient - complete resort of the tree.
I'm mainly interested in how you just store a static complete tree. No
adding/removing, just read accesses.
Drive A: not responding...Formatting C: instead