From The RT System itself

Each store starts with fetch, then changes the "value" part of HE. I
presume you understand how fetch behaves as it should. ;-)

Is the shared keys a space optimization or a time optimization?

Even Perl's malloc is yet slower than even OP dispatch. So saving a
malloc/free() is usually both space/time win.

Ilya

From The RT System itself

IZ> As I already said, shared keys break this idea. Hmm, on the other
IZ> hand​: why would they? Just be not *overly* aggressive and do not
IZ> share keys which correspdond to the same strings with different
IZ> "octets representation".

For my edification, what would happen if two 'identical' keys with
different representations were inserted into the same hash? How
would they end up in the same bucket?

Is the shared keys a space optimization or a time optimization? If it
is a time optimization how would you ensure that they locate the same
bucket?

<chaim>
--
Chaim Frenkel Nonlinear Knowledge, Inc.
chaimf@​pobox.com +1-718-236-0183

From The RT System itself

Is the shared keys a space optimization or a time optimization?
Even Perl's malloc is yet slower than even OP dispatch. So saving a
malloc/free() is usually both space/time win.

Unless of course you end up with a bunch of shared keys with only one
reference...

mark (who wants to investigate that further... how to "guess" *cheaply*
  whether a key should be shared or not... and be right more often
  then the reference count that might have been achieved...)

--
markm@​nortelnetworks.com/mark@​mielke.cc/markm@​ncf.ca __________________________
. . _ ._ . . .__ . . ._. .__ . . . .__ | CUE Development (4Y21)
|\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ | Nortel Networks
| | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada

  One ring to rule them all, one ring to find them, one ring to bring them all
  and in the darkness bind them...

  http​://mark.mielke.cc/

@iabyn - Status changed from 'stalled' to 'resolved'

@iabyn - Status changed from 'stalled' to 'resolved'