explain "3" in terms of your comp sci 101 divine computer law... Ok I get itttt "len/ptr/capa/shared". I've never written an interpreter so I can't rewrite the implementation myself, but I've worked with Rails enough to know that Ruby's is terribly inefficient, and these are problems created in it's abstraction from C, not inherent to C. Maybe this RString case is a minor issue, but it seems to me to lack some rigorousness, to be a performance leak. It's one of those things that makes you wonder "What Would Linus Do?". Although I do understand the points about including it AT ALL to be "free gain, little loss" and the language can't be C, but sometimes I don't know....
Just admit that maybe something is wrong here. Please. you'll be the first Rubyist ever, the dawn of a golden era. I've been intrigued more and more by the Lisp community because many of those devs seem to have a philosophical unwillingness to compromise performance and proper engineering, whereas in Ruby people get mad at you for not embracing the compromises!! Geez.
Hint: writing "Hint:" and then saying something really obvious that you learned from the article we all just read makes you sound craaaaaazy obnoxious
(Incidentally, it's issues like this that make me thank my lucky stars I do my web work on the JVM now.)
Haha, oh, I'm not a rubyist. Far from it; I'm a systems programmer. My ruby experience comes from writing add-ons for a hobbiest video game engine. I agree that ruby is often quite inefficient.
However, in this case, the number 23 comes from the amount of space that would be needed to store the smallest string in heap memory after taking into account malloc's bookkeeping info and whatnot.
As an aside, if you already knew the answer, why go on a rant that makes you seem ignorant?
I mean I understand the logic of optimizing for cases when you are going to be less than the lower-bound of data you can throw to the heap as you explain. I guess my question (I am honestly asking this one) is why not use the struct char array approach or some variant of it to optimize in the other direction as well (using 256 as the limit, for example, since it is closely associated with DB applications)? Is there a concern for wasted memory, or would it screw up their implementation of "union" or something? (I will, btw, willfully admit ignorance on some super in-depth C mechanics but I don't think it invalidates my point.)
I've heard of cases where Ruby performance supposedly increased tremendously because of raising some memory / garbage collection limits, and in today's world I always wondered why they don't try harder to make the sacrifice on memory footprint in order to gain speed. As a platform that is to this day routinely blasted for being so damn slow (I'm sure a lot of this falls on Rails' shoulders especially since ActiveRecord still was glacial when I stopped following... ~1.3 seconds of Ruby processing to render simple pages IIRC) why not start inserting some performance hacks or re-implementing with performance as top priority?
The answer to your question is that I'm sociopathic on the internet.
It would be a tremendous waste of memory, as a large percently of strings are small. It would also be a massive slowdown for any situations where you are copying a big string unchanged (in which case Ruby "just" marks the string as "copy on write") or where you are copying a small string.
As for slowness, there are many, many obvious targets much higher up the list than String. Slow method dispatch being the primary culprit.
I feel you..... I was more wondering if there was some better compromise point between pre-allocated / dynamic but as you say, there are tradeoffs.
You're right, there must be a lot more low-hanging fruit out there. Something interesting though... isn't the Ruby interpreter just a standard (RubySpec)? JRuby (and Rubinius I think?) are other, better-performing implementations, correct? I've been thinking about trying JRuby since I was looking into Grails and thought "eh why not just try JRuby on Rails".
but i've kinda gone in the other direction anyway and am more interested in Clojure > Ruby, especially since Clojure "frameworks" are just dead simple libs. It's weird because RoR was around first (I think, maybe some overlap in development...) but it seems that now that Clojure and Scala exist, RoR is kindof like a bad compromise between the two.
Though Clojure is kindof minimal and not everyone is singing Scala's praises...
#define RSTRING_EMBED_LEN_MAX ((int)((sizeof(VALUE)*3)/sizeof(char)-1))
explain "3" in terms of your comp sci 101 divine computer law... Ok I get itttt "len/ptr/capa/shared". I've never written an interpreter so I can't rewrite the implementation myself, but I've worked with Rails enough to know that Ruby's is terribly inefficient, and these are problems created in it's abstraction from C, not inherent to C. Maybe this RString case is a minor issue, but it seems to me to lack some rigorousness, to be a performance leak. It's one of those things that makes you wonder "What Would Linus Do?". Although I do understand the points about including it AT ALL to be "free gain, little loss" and the language can't be C, but sometimes I don't know....
Just admit that maybe something is wrong here. Please. you'll be the first Rubyist ever, the dawn of a golden era. I've been intrigued more and more by the Lisp community because many of those devs seem to have a philosophical unwillingness to compromise performance and proper engineering, whereas in Ruby people get mad at you for not embracing the compromises!! Geez.
Hint: writing "Hint:" and then saying something really obvious that you learned from the article we all just read makes you sound craaaaaazy obnoxious
(Incidentally, it's issues like this that make me thank my lucky stars I do my web work on the JVM now.)