Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Very poor performance #201

Open
bbkr opened this issue Feb 7, 2021 · 1 comment
Open

Very poor performance #201

bbkr opened this issue Feb 7, 2021 · 1 comment

Comments

@bbkr
Copy link

bbkr commented Feb 7, 2021

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:

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

@rbt
Copy link
Collaborator

rbt commented Jan 18, 2022

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants