Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Re: [LONG] Possible utf8 implementation #587

Closed
p5pRT opened this issue Sep 20, 1999 · 6 comments
Closed

Re: [LONG] Possible utf8 implementation #587

p5pRT opened this issue Sep 20, 1999 · 6 comments

Comments

@p5pRT
Copy link

@p5pRT p5pRT commented Sep 20, 1999

Migrated from rt.perl.org#1444 (status was 'resolved')

Searchable as RT1444$

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Sep 20, 1999

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

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Sep 20, 1999

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

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Sep 20, 1999

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/

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Apr 22, 2003

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

@p5pRT p5pRT closed this Apr 22, 2003
@p5pRT
Copy link
Author

@p5pRT p5pRT commented Apr 22, 2003

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

1 similar comment
@p5pRT
Copy link
Author

@p5pRT p5pRT commented Apr 22, 2003

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
1 participant