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 at http://groups.google.com/group/sequel-talk?hl=en.
