From: Rodrigo Rosenfeld Rosas Date: 2013-02-08T03:12:56+09:00 Subject: [ruby-core:51995] Re: [ruby-trunk - Feature #7797] Hash should be renamed to StrictHash and a new Hash should be created to behave like AS HashWithIndifferentAccess This is a multi-part message in MIME format. --------------070200090505000102070404 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Em 07-02-2013 13:51, Yorick Peterse escreveu: > ... >> And for the performance argument I really believe symbols cause more >> harm than good to the overall performance given all conversions that >> it will require in most code bases (even if you don't do that directly >> it is likely that you rely on some gem that will do that). > > I'd be interested in seeing the actual numbers for this. I also find it > interesting to see that your general opinion seems to be "the > performance overhead of this change is not important" yet you do seem to > care about the overhead of converting Symbols to Strings. I find this a > rather contradicting opinion but maybe I'm misunderstanding things. https://gist.github.com/rosenfeld/4732737 So, if your program relies on HWIA behavior and is converting regular hashes into HWIA, it would perform much worse then if the hash syntax already created HWIA. Also libraries like Sequel will call to_sym on string values returned from the database as column names. Then the overall performance would be slower due to unnecessary conversions between symbols and strings that wouldn't be required if regular hashes behaved like HWIA. And this is just a simplistic case. What if I had to scan an entire random object resulted from a call to JSON.parse and find all hashes to manually replace them by a HWIA version? This is way more common than you might expect in lots of gems and code out there. That is why I believe that the overall performance of most Ruby code in the real-world industry have their performance degraded by the existence of symbols and by them returning false when compared to equivalent strings. > ... > On another note, you also seem to be unaware that it's not trivial to > suddenly replace the usage of Hash with LazyDeveloperHash. Yes, in the > Ruby source code it might be easier but at least in the C code it's > going to take time and effort for something that has little value. You're saying that it has little value. What if someone decides that he would like to spend his (not yours) time making the required changes in the C code? Would this problem be gone? > In your other threads I gave you various examples on how you can work > around your issue You didn't understand the issue. I showed you a real example where you could show me how to optimize it but you haven't done so: https://bugs.ruby-lang.org/issues/7792#note-23 You just assumed that Sequel took the wrong decision while deciding for using symbols as keys instead of strings. Jeremy Evans (Sequel's maintainer) doesn't seem to support your opinion on that and explains why he thinks Sequel should keep using symbols as keys. But this is a real gem used in a real-world application published in the web. And this application would not only be easier to write and maintain if hash syntax created HWIA but this app would also perform better. --------------070200090505000102070404 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Em 07-02-2013 13:51, Yorick Peterse escreveu:
...
And for the performance argument I really believe symbols cause more
harm than good to the overall performance given all conversions that
it will require in most code bases (even if you don't do that directly
it is likely that you rely on some gem that will do that).

I'd be interested in seeing the actual numbers for this. I also find it
interesting to see that your general opinion seems to be "the
performance overhead of this change is not important" yet you do seem to
care about the overhead of converting Symbols to Strings. I find this a
rather contradicting opinion but maybe I'm misunderstanding things.

https://gist.github.com/rosenfeld/4732737

So, if your program relies on HWIA behavior and is converting regular hashes into HWIA, it would perform much worse then if the hash syntax already created HWIA. Also libraries like Sequel will call to_sym on string values returned from the database as column names. Then the overall performance would be slower due to unnecessary conversions between symbols and strings that wouldn't be required if regular hashes behaved like HWIA.

And this is just a simplistic case. What if I had to scan an entire random object resulted from a call to JSON.parse and find all hashes to manually replace them by a HWIA version?

This is way more common than you might expect in lots of gems and code out there. That is why I believe that the overall performance of most Ruby code in the real-world industry have their performance degraded by the existence of symbols and by them returning false when compared to equivalent strings.

...
On another note, you also seem to be unaware that it's not trivial to
suddenly replace the usage of Hash with LazyDeveloperHash. Yes, in the
Ruby source code it might be easier but at least in the C code it's
going to take time and effort for something that has little value.

You're saying that it has little value. What if someone decides that he would like to spend his (not yours) time making the required changes in the C code? Would this problem be gone?

In your other threads I gave you various examples on how you can work
around your issue

You didn't understand the issue. I showed you a real example where you could show me how to optimize it but you haven't done so:

https://bugs.ruby-lang.org/issues/7792#note-23

You just assumed that Sequel took the wrong decision while deciding for using symbols as keys instead of strings. Jeremy Evans (Sequel's maintainer) doesn't seem to support your opinion on that and explains why he thinks Sequel should keep using symbols as keys.

But this is a real gem used in a real-world application published in the web. And this application would not only be easier to write and maintain if hash syntax created HWIA but this app would also perform better.

--------------070200090505000102070404--