From: Eric Mahurin Date: 2008-02-11T13:03:27+09:00 Subject: Re: very bad character performance on ruby1.9 ------=_Part_35468_16270426.1202702614277 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On Feb 10, 2008 12:33 PM, Eric Mahurin wrote: > The problem of course is that every character in ruby 1.9 becomes a normal > ruby object (String) in ruby 1.9, whereas in ruby 1.8 they where > immediates (Fixnums). > > I'd like to propose that at least ASCII characters in ruby 1.9 be made > into immediates: > > * at a minimum, characters should be read-only/frozen. Allowing them to > be mutable will inhibit many future optimizations. > * give (small) characters a separate class with string-like (read-only) > functionality. > * possibly add a base class that String and this new character class would > be a descendent of. > * eventually make this small (i.e. ASCII or even unicode) character class > have immediate objects > > If the above was done, one of these immediate characters would be to a > Fixnum as a frozen String would be to Bignum. A possible base class of > these would be in line with the Integer class. Hi Matz, Could you comment on these character-access performance issues in Ruby 1.9. The last I've seen this discussed is in 2005: http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/4146 Are there any plans to address character-access performance issues to get back to the 1.8 performance levels? The minimum I ask is that methods returning characters return a frozen String instead of a mutable String. This will make it possible to do future optimizations without affecting compatibility. Ruby 1.9 code should also not make many assumptions about the "character" objects returned from methods (represented as a String right now): * the class might change in the future * two #==, but independently generated character objects might be the same object * shouldn't modify these character objects Thanks, Eric ------=_Part_35468_16270426.1202702614277 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On Feb 10, 2008 12:33 PM, Eric Mahurin <eric.mahurin@gmail.com> wrote:
The problem of course is that every character in ruby 1.9 becomes a normal ruby object (String) in ruby 1.9, whereas in ruby 1.8 they where immediates (Fixnums).

I'd like to propose that at least ASCII characters in ruby 1.9 be made into immediates:

* at a minimum, characters should be read-only/frozen.  Allowing them to be mutable will inhibit many future optimizations.
* give (small) characters a separate class with string-like (read-only) functionality.
* possibly add a base class that String and this new character class would be a descendent of.
* eventually make this small (i.e. ASCII or even unicode) character class have immediate objects

If the above was done, one of these immediate characters would be to a Fixnum as a frozen String would be to Bignum.  A possible base class of these would be in line with the Integer class.


Hi Matz,

Could you comment on these character-access performance issues in Ruby 1.9.  The last I've seen this discussed is in 2005:

http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/4146

Are there any plans to address character-access performance issues to get back to the 1.8 performance levels?

The minimum I ask is that methods returning characters return a frozen String instead of a mutable String.  This will make it possible to do future optimizations without affecting compatibility.

Ruby 1.9 code should also not make many assumptions about the "character" objects returned from methods (represented as a String right now):
* the class might change in the future
* two #==, but independently generated character objects might be the same object
* shouldn't modify these character objects

Thanks,

Eric

------=_Part_35468_16270426.1202702614277--