DBIish icon indicating copy to clipboard operation
DBIish copied to clipboard

Very poor performance

Open bbkr opened this issue 4 years ago • 1 comments

I'd love to use Raku in more demanding projects but currently performance of DBIish is far from being acceptable. I've created simple benchmark - execute 100K prepared queries that accepts one argument and returns single row as Hash.

Results on my machine:

  • Perl - https://gist.github.com/bbkr/d9d175c981c0a233af5bd3a4c4a3ebe0 - 10.7s
  • Python - https://gist.github.com/bbkr/bb6bd31dab1654dc6fb35023788c6196 - 15.3s *
  • DotNet - https://gist.github.com/bbkr/3a8f3b1c72eaf4d29bd8f6b21da192eb - 11.0s
  • Raku - https://gist.github.com/bbkr/44c61fdfd3bdc410146e3dea8ab7493c - 51.7s

This is general issue about lack of optimizations in DBIish. I do not have any ready to implement advice here. But being 3-5 times slower than competition in databases area is serious blocker in wider Raku adoption.

* Python was not using server-side prepared statements

bbkr avatar Feb 07 '21 13:02 bbkr

There have been some improvements on this over the past year, mostly (I think) from the new dispatch mechanism being used by NativeCalls.

With PostgreSQL using your test code (driver/username/password changed) I get:

  • Perl: 1.9s
  • Raku: 7.3s

Nearly 1.4s of that is creating :hash'd results. Using $statement.row() for array results it's 5.9s.

Some of the remaining gap will be closed with expected performance improvements to LEAVE {} handling in a near-future version of Raku.

rbt avatar Jan 18 '22 14:01 rbt