From: Robert Klemme Date: 2004-10-12T23:04:36+09:00 Subject: Re: Ruby Directions (was Re: quality of error messages) "Alexander Kellett" schrieb im Newsbeitrag news:20041012131335.GA13351@loki... > On Tue, Oct 12, 2004 at 10:23:12PM +0900, Gavin Sinclair wrote: > > Perhaps there are some uses of strings for which immutability makes > > performance sense, and some uses for which it doesn't. I couldn't be > > bothered thinking about it :) > > i can't imagine many cases where its less performant in fact. > immutable strings with cow are obviously far faster for copying > than mutable strings First of all you can have mutable strings with cow, too. In fact, Ruby Strings do just that. And if they do, mutable Strings are better performance wise if you want to do inplace modification. Consider s = s.gsub(/x/, 'u') vs. s.gsub!(/x/, 'u') The first is slower because of the new String instance: 15:58:47 [ruby]: ruby stringperf.rb user system total real gsub! 3.282000 0.000000 3.282000 ( 3.322000) gsub 3.343000 0.000000 3.343000 ( 3.329000) 15:58:56 [ruby]: cat stringperf.rb require 'benchmark' include Benchmark N = 10000 sample = ("foulx" * 100).freeze bm(20) do |b| b.report("gsub!") do N.times do s = sample.dup s.gsub!(/x/, 'u') end end b.report("gsub") do N.times do s = sample.dup s = s.gsub(/x/, 'u') end end end > and as with most systems its the copy / > construction of strings rather than the iteration that takes > the time i'd say its logical that they should be immutable. As I said, this totally depends on the use case. There are pros and cons to both. > (if you look at the most common c/c++ programs (excepting apps > using trolltech's qt which solves the problem fairly neatly) > you'll see that strcpy and memory allocation take up a huge > chunk of execution time) > > still... for coding, i love slice! / gsub! etc. they are > amazingly useful constructs. i can't imagine living without > them :) You see? :-) Kind regards robert