[Freeciv-Dev] Re: [RFC] Attaching information to objects

[Falk Hueffner <falk.hueffner@xxxxxxxxxxxxxxxxxxxxxxxx>]

Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx> writes:

> On Sat, Jan 13, 2001 at 05:46:28PM +0100, Falk Hueffner wrote:
> > Brian Olson <locke@xxxxxxx> writes:
> > I've another suggestion: it might suffice to submit just a single
> > 32-bit int to the server as a key.
> > 
> > A client would usually have just a few "jobs", like worklist, or
> > gotos, or the mentioned tile improvement plan. So it could mangle the
> > job ID in 1 byte and the unit ID/tile coord/etc. into the lower 24
> > bits. The server would then only need a single hash table for each
> 
> To quote D. E. Knuth: "Premature optimization is the root of all
> evil." It is IMHO insubstantial if the packet payload is 4 , 8 or even
> 20 bytes.

I was not thinking of any size or time saving, but of code saving,
which is certainly not what Knuth considered evil... It's just that
using anything <= 4 bytes as key simplifies using hashes *A LOT*
because of the way it is currently implemented. If we were using C++
for example, it wouldn't matter at all.

> > player, where it would stuff the key directly into the void* of the
> > hash_bucket. The client would cache it in the same format. Very easy
> > to implement. The client would have some convenience functions like
> > 
> > enum client_data { CD_PUBLIC_WORKER, CD_TILE_IMPROVEMENT };
> > 
> > /* cache attribute and send it to the server */
> > void set_attrib(enum client_data type, int id, int len, const char *data);
> 
> It is needed in the client and the server to lookup based the
> compound key <object type/class (city, tile, unit, player), id,
> object type special subkey>. If I understood you correctly you want
> to a lookup based on <client_data, id> where client_data contains
> information about object type and the object type special
> subkey. However we have a hopefully fast lookup for <object
> type/class (city, tile, unit, player), id>: the normal *_find_*
> methods. Only the last step (looking up the object type special
> subkey) is additional and can be implement easy (static array) if
> this subkey space is dense and the total amount known.

Well, again I didn't think of any speed gains. I just wanted to keep
things as easy as possible...

        Falk