Beefy Boxes and Bandwidth Generously Provided by pair Networks
laziness, impatience, and hubris
 
PerlMonks  

Re: Any Point in Uploading Tie::SortedHash

by Abigail-II (Bishop)
on Sep 05, 2003 at 22:20 UTC ( [id://289373]=note: print w/replies, xml ) Need Help??


in reply to Any Point in Uploading Tie::SortedHash

Level 2: Identical to level 1 only faster. The array with sorted keys and hash lookup table are only recreated when a new key is added, a value is changed, or the sort routine is changed.

That's not necessarely faster. It depends on how often you are inserting and how often you are asking for the keys. What you could do is some form of hybrid:

  • Create an array @sorted, and a variable $clean, initially set to 0.
  • If FIRSTKEY is called, check the value of $clean. If it's true, @sorted contains the sorted keys. If false, fill @sorted with the sorted keys of the hash, and set $clean to 1.
  • If you insert a key in the hash, or change the sort order, or delete something from the hash, set $clean to 0.
  • This might cause some bizarre results if you modify a hash while iterating over it, but that may happen with normal hashes too.

Deleting a key doesn't require a rebuild because the element is deleted from the array and the lookup hash.

Are you aware that deleting an element from an array can take time linear in the size of the array?

Abigail

  • Comment on Re: Any Point in Uploading Tie::SortedHash

Replies are listed 'Best First'.
Re: Re: Any Point in Uploading Tie::SortedHash
by Limbic~Region (Chancellor) on Sep 05, 2003 at 22:31 UTC
    Abigail,
    My verbiage was incorrect. The code is a hybrid as you describe. The rebuild does not happen when a key is deleted, value is changed, etc. Only a flag is set that is checked when FIRSTKEY is called. A rebuild only happens under those circumstances.

    In reference to deleting an array element taking time in linear proportion to the size of the array, no I was not aware of this. The two alternatives I can think of are:

  • Set the CHANGED flag and rebuild if FIRSTKEY is ever called again
  • Use more memory and delay the delete(s) until FIRSTKEY is called again. If in the interim the hash is modified, the rebuild would occur and the delete(s) would be forgotten. If FIRSTKEY was never called again, they would also be forgotten (albeit using some memory).

    Do you see a clear way to go?

    Cheers - L~R

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://289373]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others about the Monastery: (3)
As of 2025-06-23 13:20 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found

    Notices?
    erzuuliAnonymous Monks are no longer allowed to use Super Search, due to an excessive use of this resource by robots.