[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
VERSTEEGH@xxxxxx writes:
>>> 1 new api function: set_cache_size(int nr_of_files_to_cache)
>>
>> I'd prefer to leave this out.
>
> Ok, I can completely hide it , but then we need to come up with a sensible
> default.
I'd say just the most recently hit file if you are caching an entire
datafile as a single entity, or if you treat nested datafiles inside it as
separate things, probably four would be good.
> Anyway, I'd like to have a way to turn it off
Why? It's not as if this is a difficult performance tradeoff that needs to
be tweaked. I can't actually imagine that anyone would ever want to tweak
it, so adding this function can only serve to complicate the issue and
distract people from the more important issue of what the code does. They
shouldn't need to know or care the details of how it does it...
>> Cool. But don't forget about pack_fopen("x.day#y").
>
> Isn't pack_fopen_special_file used by load_datafile_object?
No, they are totally separate implementations. But should obviously be
merged now the code is getting more complex.
> I doubt about nested datafiles at the moment. I'm not sure if it works
> right now, it should work if you include them as binary object and use the
> parent#child notation as filename. Does load_datafile_object work for
> objects in nested datafiles?
No (although really it should be: there's another thing to add!), but the
"parent#nested#child" notation is recursive, and it would be good to have
the cached indexes working for that.
> I'm not sure if it would be worth the trouble to add caching for the
> indexing of nested datafiles (it would get quite hairy, while now it's
> nice&elegant)
That's why I suggested just building the cache in a single pass when the
file is first touched, rather than on the fly while looking for the object.
That loses very little performance (on average double the index scanning for
a single object access, but as you access increasingly more objects from a
single file, this tends towards no performance loss at all, and performance
is only important when many objects are being read), and it would hugely
simplify the code. With a separate index pass, the algorithm would look like:
if (no cache for this file)
load_index();
return object position from index, or NULL if it isn't there;
That's simple enough that you can make it recursive without any problems, so
it would do this once to locate the location of the nested datafile inside
the parent, then again to read and use the index of that nested file, and so
on until it got down to the actual object...
--
Shawn Hargreaves - shawn@xxxxxxxxxx - http://www.talula.demon.co.uk/
"A binary is barely software: it's more like hardware on a floppy disk."