Re: Two Advanced Ruby Performance Questions

To M. Edward

Thanks for the info. In terms of VM, basically I'm looking for something 
that is significantly faster than Ruby is right now. Ultimately it would 
have been nice to start clean on Ruby 2.0 semantics and its upcoming VM 
but I don't have much confidence on timelines here, especially to a 
stable build. I'd prefer jRuby because it would allow us to hook into 
Java easier which a lot of reference implementations for integration are 
done in; however, I'm worried about difference between it and the 
reference implementation.

Thanks also for the referral to "Ruby for Rails." I have read the book 
once but I wasn't thinking of scoping when I did. I will read it again. 
The information on scoping will probably be very helpful.

I have read the Pickaxe book (a couple of times now) but am not much of 
a C programmer though I have learned it in the past and I know much of 
its semantics are similar to Java/C# style without garbage collection, 
native OOP, etc.

I do have to disagree a little with your "one last comment" however. I 
find it necessary to learn everything I need to know about a language to 
scale. I find it uncomfortable when I don't know what is happening under 
the hood because things can take me by surprise.

I agree that not knowing what's going on under the hood can be a "good 
thing" if your application doesn't need to scale largely and, quite 
frankly, for about 99% of apps, you really don't need to worry that much 
about performance. But it is absolutely essential in our applications. A 
wrong choice early on or a lack of knowledge could mean we run into 
possibly unsurmountable problems later.

As an example, I know that MS SQL server keeps statistics on all of its 
tables and makes optimization decisions on which indexes to use based on 
those statistics. One night, our application slowed to a complete crawl. 
It stopped serving pages and yet we couldn't recall any change we made 
to the code that would cause it. We traced it to the DB and what 
happened was that one of our partners added a huge number of products to 
our db. This in itself wasn't a problem as our indexes are designed to 
scale to a large number of products; however, SQL Server incorrectly 
started choosing the wrong index and performance went down by something 
like 100x - 1000x. Obviously, it was using bad logic to decide which 
index to use; however, if I didn't know that the optimizer used table 
stats to make decisions on which index to use, we would have likely been 
stuck looking in the wrong area. The change in table size changed the 
stats and the index used change. As it were, we rewrote the query such 
that we provided more hinting to the database and then MS SQL Server 
started using the correct index again.

I like knowing this type of stuff so I know what happened when things go 
wrong and to prevent it from happening in the first place.

Jan Svitok,

Thanks for the incredible information. I feel like you've got an 
understanding of how Ruby works underneath and have some interesting 
approaches to boot. Just the names of the useful projects has helped 
immensely.

> It is said that method call overhead in ruby is pretty high, partially
> due to the possibility of being able override an existing method
> later.

Thanks for the warning. Actually, I think I mispoke a little. I should 
have said the overhead of specific methods. Although I have timed method 
calls in ColdFusion and the call time differs depending on where the 
methods are called from (e.g. methods in objects take a longer to call 
than local methods), I haven't found the overhead to be a problem. Like 
Ruby, method calls in ColdFusion are done through a lookup and they can 
be modified at runtime so I expect similar call times. Object 
instantiation, however, was crippling and certain specific methods took 
too long to execute and were rewritten (like the WDDX call).

> Both ERB and eRuby will compile your template into a string that will
> get 'eval'ed. The difference is that ERB uses print statements and is
> therefore hard to capture.
> Have a look at erubis -- ERB implementation in C (I haven't tried it 
> myself).

Thank you. I will take a look at erubis.

Thanks also for the information on Mongrel. This project sounds 
interesting. I am disappointed to learn that Rails is not thread safe. I 
am still hoping that ActiveRecord will work well in a multi-threaded 
environment however. The approach of multiple instances of mongrel and 
multiple ruby interpreters is a good workaround. That said, I think I'd 
have to rewrite ActiveRecord anyways as it relies on config files to set 
datasources and such. Our application will probably need to set 
datasources at run time so that we can split a table across multiple db 
servers and let it know, at run-time, which server the data resides on.

Also, your information on persistence is useful; however, I'm still 
unclear about a few things.

I can't wrap my head around when something becomes bound to the "global" 
scope and when it is bound to a "request" scope. I'm defining "global" 
to mean from the application start to its end and "request" scope to 
mean the life of one request.

For example, if I "require" a file with a class, that class will now 
become part of the global scope. But what if I define a method in the 
"require"d file as well? Does that method become part of the global 
scope?

If a "require"d file becomes part of the global scope always, is there 
any way to create a class that IS NOT part of the global scope.

Also, if a single request say modifies the "class" at runtime by adding 
methods to it, does this change persist into all the other request or 
does the change only persist for the one request? What if the class is 
modified in non-"require"d code?

I understand if this is too many questions for you. Just wanted to say 
thanks either way for the information provided. It's nice to have lots 
of useful experts online.

Sunny Hirai
CEO, MeZine Inc.

-- 
Posted via http://www.ruby-forum.com/.