I couldn't wait until Monday to try more with SQL Server, so I switched over to MySQL and played some more with JRuby vs. Ruby and decided to blog about it:
http://ramblings.gibberishcode.net/archives/a-comparison-jruby-vs-ruby-mri-with-sequel/74 MySQL more or less reflected similar numbers a SQL Server seemed to be reflecting. If y'all think its still worth filing a report with the JRuby folks, I can still do that, but one thing I know is that I'm not on the latest JRuby and not much time to invest in pursuing this further at the moment. At any rate, a full script is provided so anyone can pick it up and continue if they desire. Enjoy! Michael On Apr 24, 10:34 am, Charles Oliver Nutter <[email protected]> wrote: > If splitting across threads doesn't help, that lends more weight to > the possibility that the bottleneck is not CPU related. It could be > the type conversion as someone else mentioned, or it could be a flaw > in JRuby or Sequel that can be corrected. > > Another flag you can try (there's dozens of them, of course!) would be > passing -J-verbose:gc or -J-XX:PrintGCDetails to JRuby. This turns on > GC logging in the JVM. If you see hundreds and hundreds of GC runs, > either JRuby or Sequel are being too wasteful about objects. If you > see a lot of "Full" GCs, that's even worse; they're complete stop-the- > world heap collections, and for most applications they should happen > rarely. > > Another one to run (in client mode...it lies in server mode) would be > --sample, which turns on the JVM's sampling profiler. It may or may > not show Ruby code, but it will definitely show Java methods that are > getting hit hard. The results aren't super accurate, but they can > often find egregious bottlenecks. > > My money is on the object churn and GC overhead though; that's usually > what bites Ruby apps right now, and JRuby's objects are a bit larger > than MRI's. > > On Apr 23, 10:38 pm, Michael Lang <[email protected]> wrote: > > > > > Here's a variation of the clone method where I slice the dataset up into 4 > > chunks and imported each within its own thread. The first run I did worked > > and executed in about 7.5 minutes vs. the 9 minutes of the single thread > > approach, but the 2nd, 3rd, 4th runs I attempted never quite got off the > > ground with only the 3rd run actually cloning about 2500 records while the > > others cloned zero. I thought maybe my attempt to update the progressbar > > from each of the threads was a problem, so I commented the pbar lines > > altogether to no good effect. > > >http://gist.github.com/377437 > > > Isn't one of the hypes of JRuby its "true threading" model? Or am I > > misunderstanding that claim altogether in my attempt to utilize the Thread > > class to divide and conquer as I did here? > > > I'm totally baffled because the first run actually ran and worked! The > > statistics in the jconsole were not appreciably different than previously > > reported. > > > Charles, your post came in as I wrote this. I'll give the benchmark page a > > read and the server mode a go and see what I churn out with the original > > approach on Monday when I'm back in the office. > > > Michael > > --http://codeconnoisseur.org > > > -- > > You received this message because you are subscribed to the Google Groups > > "sequel-talk" group. > > To post to this group, send email to [email protected]. > > To unsubscribe from this group, send email to > > [email protected]. > > For more options, visit this group > > athttp://groups.google.com/group/sequel-talk?hl=en. > > -- > You received this message because you are subscribed to the Google Groups > "sequel-talk" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group > athttp://groups.google.com/group/sequel-talk?hl=en. -- You received this message because you are subscribed to the Google Groups "sequel-talk" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/sequel-talk?hl=en.
