Thank you for information, Jeremy. Yes, my queries are tuned right now to the point where I see no further ruby-side tuning possible without changing either functionality or database schema.
I will give a try to memprof, hopefully it provides better picture than ruby-prof in memory allocation mode. I tried already using raw postgres driver, and yes, it is the fastest way, indeed, but I am hesitant to go that way because of maintainability issue. Also, I have seen that using Sequel to prepare queries for me in form of prepared statements is quite close to performance of raw driver, it is only slower by about factor of 2 (versus factor of 10-40 when using fully fledged ORM with on-demand-built queries). That would be a very acceptable compromise - using Sequel to build the queries once (expensive process), and then using prepared statements to execute them. Current Sequel's performance is very much acceptable - it is way better that any other non-driver database access that I have tried, the only issue is increased GC churn. Still, it is likely that I will go this exact way in the near future (what I am doing now is just a short spike to learn how to rewrite existing system), but it would be great to figure out/reduce some of that GC churn. Thanks again for your help, and ... Happy New Year to you :) On Dec 30, 9:18 pm, Jeremy Evans <[email protected]> wrote: > On Dec 30, 6:01 pm, Olek Poplavsky <[email protected]> wrote: > > > Thank you for suggestion, Jeremy. > > > Installing this gem had an interesting effect. Cost of one action > > execution in ruby-prof dropped significantly, from 40k to 20k of > > 'process time units'. > > Quick test showed that 'best case scenario' action processing time > > dropped from 7ms to 6ms. > > Stress tests showed relatively small improvement in throughput (31 to > > 33 for untuned ruby and 41 to 43 for gc-tuned ruby). Amount and total > > size of short lived objects stayed about the same, so did overall > > garbage collection time. > > > All in all, it is definitely worth it to use sequel_pg gem, but it did > > not affect short lived object's generation rate. > > Interesting. Usually sequel_pg provides more of a speedup, but I > suppose if your queries are already highly tuned, it may not make as > much difference. > > If you want to see where the intermediate objects are being created, I > would recommend trying the memprof gem. If you send the output of > memprof, it should be possible to determine where the intermediate > objects are getting created. > > If you looking for additional ways to increase the speed, you could > drop down to the driver level: > > DB.synchronize do |conn| > conn # PGconn instance > end > > This makes things a lot less friendly, but it is probably the fastest > you can make things in pure-ruby code, with any additional speedups > requiring writing a C extension. > > Thanks, > Jeremy -- 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.
