From: Sunny Hirai Date: 2006-11-27T19:15:54+09:00 Subject: 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/.