R: [AD] Allegro 5 new config routines, alpha 1

[ Thread Index | Date Index | More lists.liballeg.org/allegro-developers Archives ]


> I don't see why the parts of the name have to be parsed out. 
> With an efficient enough hashing algo, you can just look up 
> each item by it's full 'path'. This way takes up lots less 
> memory, and allegro doesn't really require the multilevel 
> hashing scheme as it won't have thousands upon thousands of entries.

The reason why the names are broken up is simple: it makes the load/save
of subtrees easy to manage. This way you can easily load all the config
vars of a file into a new config "subdirectory"... Same goes for the
saving issue. Having all entries stored into an unique table could make
such features much harder to implement, even if it's not an impossible
task.
In addiction, having an unique table could result in more collisions,
also between entries belonging to different directories... Which is Not
Good.
All in all, most of our config entries will probably not have more than
3-4 subdir levels, resulting in 3-4 hash scans. If the hash function is
fast enough (as I think it should be, but suggestions to improve it are
welcome!) speed won't be an issue. About size, if we use say 512 entries
tables, we have 16K per table, and even supposing to have 20 tables (one
for each directory ever referenced), that's 320K which is not that big.
At least IMHO.

--
Angelo Mottola
a.mottola@xxxxxxxxxx
http://www.ecplusplus.com



Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/