Re: Sv: Sv: Strangest thing happened; ...

[Christian Reiniger <warewolf@mayn.de>]

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
>pak
>>>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.


	Christian
--

Drive A: not responding...Formatting C: instead