Subject | Re: [IB-Architect] Identifier naming woes |
---|---|
Author | Jim Starkey |
Post date | 2001-05-25T15:00:46Z |
At 10:34 AM 5/25/01 -0400, David Jencks wrote:
for scholarly papers than software. There are no significant
issues on hash table organization for a string registry than
the engine currently has for table name space. Just not worth
losing sleep over. Cycles are sooo cheap and memory soo plentiful
that worrying about compile time overhead borders on pointless.
which (mod table size) is used an index into the hash table,
locating a linked list of hash collisions. The engine loops
through the hash collisions doing string compares against the
string until a match is found or the list ends. The string
compares are modestly expensive, requiring either a function
call or a significant gob of inline code. The string registry
substitutes an address comparison for the string compare.
The good part is that string registry is probably three or four
times faster. The bad part is the difference is probably on the
order of milliseconds per day.
If you grew up on a VAX where a CALLS could take 40 (or more)
microseconds you'd care. Now worrying about this sort of thing
is a major indication of old-fartism.
zealot that anything less than infinitely is crime against
Knuth. But providing the API with explicit control of search
order allows some absolutely magic things to happen.
Jim Starkey
>>That's simple -- you blow 32 bit virtual address space and crash.
>
>How do you know how large is large enough? If I start with an empty db and
>proceed to create 2 billion empty tables, what happens?
>
>> I've never been a fan of fancy hashing schemes. There are twoWhat I'm arguing is that fancy hashing schemes make better topics
>> cases.
>
>I'm not sure what you're getting at. The only purpose I know of for things
>like extensible linear hashing is to solve the "how large is large enough"
>question. Is there another way? As I said, I'm not an expert.
>>
for scholarly papers than software. There are no significant
issues on hash table organization for a string registry than
the engine currently has for table name space. Just not worth
losing sleep over. Cycles are sooo cheap and memory soo plentiful
that worrying about compile time overhead borders on pointless.
>>A typical symbol lookup begins with a hash function on a string,
>
>Now I'm sure I don't understand which operations this would help. Can you
>be specific and perhaps point out which files the ugly code is in?
>
which (mod table size) is used an index into the hash table,
locating a linked list of hash collisions. The engine loops
through the hash collisions doing string compares against the
string until a match is found or the list ends. The string
compares are modestly expensive, requiring either a function
call or a significant gob of inline code. The string registry
substitutes an address comparison for the string compare.
The good part is that string registry is probably three or four
times faster. The bad part is the difference is probably on the
order of milliseconds per day.
If you grew up on a VAX where a CALLS could take 40 (or more)
microseconds you'd care. Now worrying about this sort of thing
is a major indication of old-fartism.
>Are multi-level namespaces kind of like SQL schema but better?I think two levels are ok, but I'd have trouble convincing a
>(level1.level2.level3.myrealobject or schema.name ?)
>
zealot that anything less than infinitely is crime against
Knuth. But providing the API with explicit control of search
order allows some absolutely magic things to happen.
Jim Starkey