|
|
|
|
|
by fat0wl
4566 days ago
|
|
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. |
|
As for slowness, there are many, many obvious targets much higher up the list than String. Slow method dispatch being the primary culprit.