Re: Tied Hashes vs. Objects

From what I recall, tied hashes are measurably, but not horribly so, slower than an equivalently functioning object. I believe there are one or two extra indirections involved in method resolution.

But for that penalty, you get -- as you observed -- transparency for any and all code that need to use the 'special hash'. That is a substantial advantage in terms of developer efficiency and code-base simplicity. Two huge advantages well worth the cost of a few microseconds.

So, unless it is observable that your code is becoming a bottleneck in the overall process, don't even consider it.

If it is observable that your code is becoming a bottleneck, then profile the code -- the entire code, end to end -- and determine if those one or two extra dereferences are actually a substantial contributory factor. In most cases they will not be.

You need to be processing substantial amounts of in-memory data, very intensively, before such small differences become significant.

I have switched from a tied interface to using the method interface enabled by the object handle returned from tie, for performance reasons when performing cpu-intensive processing on huge, in-memory datasets, once or twice in the past. But as I recall, on both occasions I later found other changes that saved much more that the switch did and I reverted. The transparency of tied datasets is just too effective to discard without good reason.

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

RIP Neil Armstrong

Comment on Re: Tied Hashes vs. Objects

Replies are listed 'Best First'.
Re^2: Tied Hashes vs. Objects by Anonymous Monk on Oct 22, 2012 at 19:14 UTC
Thank you very much, this was exactly the kind of advice I was seeking. In some circles, I think, tied hashes have for some reasons gained a bad reputation, performance-wise. I could not find any references backing this, so unless proven otherwise, I'll stick with tied hashes, as you sugested.	[reply]
Re^3: Tied Hashes vs. Objects by BrowserUk (Patriarch) on Oct 22, 2012 at 21:31 UTC
As it had been a long time since I'd performed this kind of benchmark, I did one: <Reveal this spoiler or all in this thread> The results: `__END__ C:\test>b-tieHash.pl 8376437/16777216 std hash usage took: 56.582 seconds 8376437/16777216 tied usage took: 210.352 seconds 8376437/16777216 Object usage took: 126.642 seconds` [download] show that using the object interface saves 1 microsecond per key, spread across all 5 operations performed on each key/value, Say 1/5th of a microsecond (0.0000002) per operation. You need to be doing billions of hash operations -- with almost no other associated processing -- for that to become a significant part of your time costs. With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday' Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. "Science is about questioning the status quo. Questioning authority". In the absence of evidence, opinion is indistinguishable from prejudice. RIP Neil Armstrong	[reply] [d/l] [select]
Re^4: Tied Hashes vs. Objects by tkemmer (Initiate) on Oct 23, 2012 at 07:03 UTC
Thank you very much for your effort! At least to me, this really busts the "Tied Hashes are Expensive" myth, so the decision whether to use tied hashes or an object interface should definitely not be based on performance, but rather on matters of style and clarity. Thanks again!	[reply]


Syntactic Confectionery Delight
	PerlMonks