Re: Re: A memory efficient hash, trading off speed

BrowserUk suggests that Tie::SubstrHash be used as a potential solution...

I recommend that this solution not be considered. tie()'d objects have overhead. In the cheapest case, we would be replacing a small basic hash with less than 4 entries with a tied hash, and an attached blessed string reference. No gain would be realized, and performance would suffer.

Comment on Re: Re: A memory efficient hash, trading off speed - does it already exist?

Replies are listed 'Best First'.
Re: Re: Re: A memory efficient hash, trading off speed - does it already exist? by BrowserUk (Patriarch) on Feb 04, 2003 at 11:22 UTC
tie()'d objects have overhead True, but the OP said that performance was not a concern. ... would be replacing a small basic hash with less than 4 entries with a tied hash, and an attached blessed string reference. No gain would be realized ... My thought was to replace the 120_000 element hash with a Tie::SubstrHash which does make a considerable saving in space. However, as you can't use a Tie::SubstrHash to store references, that throws the idea in the bin. I have an incomplete and broken version of the standard module that attempts to work around this particular restriction, but in the absence of the abilty to build XS/Inline-C, I am unable to complete that. There's no guarentee I could bring the idea to fruition anyway. Examine what is said, not who speaks. The 7th Rule of perl club is -- pearl clubs are easily damaged. Use a diamond club instead.	[reply]
Re^4: A memory efficient hash, trading off speed - does it already exist? by diotalevi (Canon) on Feb 04, 2003 at 15:46 UTC
I think you were looking for Devel::Pointer. You'd have to find a way to manage the referent's reference count (B allows you to fiddle with it directly). If I were going to extend your module to use references I'd go this route - store the reference using the normal means and revivify it on demand. Seeking Green geeks in Minnesota	[reply]