Hi Jeremy, I've updated the benchmarks article so it's more apples to apples comparison. Here's the link if you're interested - I have colorful charts now instead of data tables. :)
https://hmistry.github.io/software/2017/12/11/activerecord-vs-sequel.html Regards, Hiren. On Thursday, December 14, 2017 at 12:35:18 AM UTC-8, Jeremy Evans wrote: > > On Wednesday, December 13, 2017 at 10:59:15 PM UTC-8, Hiren Mistry wrote: >> >> Thanks for catching the typo and missing DB constraint. I'll update them >> accordingly. Rails added FK constraints since 4.2 but I forgot to add them >> in the migration. >> >> So what you're saying and showing, is basically it's typecasting that's >> the bottleneck and more specifically timestamps in my example. The speed >> drops from ~1K to 170 without the sequel_pg gem. What makes timestamps so >> expensive compared to other data types if I may ask? >> > > Time parsing and creating time objects is in general slow. It's actually > much better now than in the ruby 1.8 days, but it's still very slow and > often the bottleneck. > > I think Rails's time parsing is faster than Sequel's default (though not > sequel_pg), probably because Sequel offers more options for how to handle > time typecasting (Time vs DateTime, database_timezone, > application_timezone, etc.) and that adds complexity and makes things > slower, plus Sequel's default needs to support many more databases than > just the 3 that AR supports. > > >> It's interesting to learn that AR delays typecasting to attribute access. >> I noticed it delaying things when calling queries and so I made sure that >> the DB queries were actually made and data gathered - that's why I forced >> some queries to return an array vs ARCollectionProxy thing. Are there other >> such optimizations (i.e. delay computation till needed) in AR and Sequel >> that I should be aware of in benchmarking? >> > > Well, it's hard to say. I'm not that familiar with modern AR internals. > I mostly know about this issue since it's basically the main case where AR > performs better than Sequel, and it's not a case I want to optimize for. > The RubyBench developers found basically the same issue in their > benchmarking. > > Thanks, > Jeremy > -- You received this message because you are subscribed to the Google Groups "sequel-talk" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/sequel-talk. For more options, visit https://groups.google.com/d/optout.
