-
Notifications
You must be signed in to change notification settings - Fork 115
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
Perf/benchmarks #347
base: master
Are you sure you want to change the base?
Perf/benchmarks #347
Conversation
Creating the benchmark if you want to look at WIP code. Not ready for a merge yet. |
a6daf40
to
5b70bca
Compare
- Extracted out code for creating a connection to the test DB - Added ‘benchmark’ section/target to cabal file
@tomjaguarpaw are you alright with a dependency on |
As long as the |
@tomjaguarpaw do benchmarks like this seem helpful to you? Should I continue down this path?
|
Travis tests all the way back to 7.6. You'll need to import |
You'll also have to not use |
In fact I don't even see that you used |
Had tried TypeApplications, but found it too confusing. Had already moved to Proxy. I'm getting strange benchmarking results. While actually running the queries, the difference between opaleye generated queries and handwritten queries wrt narrow tables is barely perceptible in the numbers. I'm going to try with wide tables, to be sure. Do you have any hypothesis why the benchmark numbers are wildly different from what we were observing in #340 ? If we aren't doing anything with the query results (like, printing them or writing them to disk), will all the query parsers (pg -> haskell conversion) get executed?
|
Let it be I found the error. I was running the Opaleye generated query instead of the handwritten query 🤦♂️ Here are the new benchmark results which clearly demonstrate that queries generated via Opaleye get progressively slower as the level of nesting increases:
|
@tomjaguarpaw should I complete this for all use-cases, eg aggregates & limit/offst AND wide-tables, or is this good enough? |
It would be best if you can complete it in for a wide range of use-cases because then we know any improvements I make are not making anything worse! |
Did you look at the |
Which numbers are the ones for |
|
@tomjaguarpaw you can take a look at the benchmarks now. The code is not pretty, but it should get the job done. Here are the benchmarks numbers on my machine:
|
@tomjaguarpaw can you help me fix the travis build? |
Oh I see. I searched for "prepareQuery" but they're called "pepareQuery" :) |
Btw, encountered #348 as well |
The build fails to install |
Regarding
It takes 300.3 μs to prepare the query and 653.9 μs to execute it, so I'd say it's worth keeping those benchmarks, wouldn't you? |
Would you be open to moving to CircleCi. We've recently spent a lot of time in making bullet-proof CircleCI builds for Haskell. |
653.9 μs includes the query preparation time. |
I'm definitely open to it. I piggy back on Neil Mitchell's |
So it's 300 μs to prepare and 353.6 μs to execute? Preparation still seems quite slow ... I think it's worth keeping both. |
I really don't understand what's gone wrong with |
What's your dev machine config? What do these numbers look like on your machine? |
I'm not at my dev machine but will try it when I am. Thanks! |
I have an underpowered laptop but I'm sure the relative stats are the important thing :) |
@tomjaguarpaw I've added the prepareQueryBenchmarks for a few cases as well. Let me know if you need anything else. You can run these tests interactively as well, eg:
|
Thanks very much for doing this. I hope to look at it this weekend. |
I haven't forgotten about this but will get round to it when I have some time. |
Thanks for the update 😄 |
@tomjaguarpaw ping. |
I still haven't forgotten but sorry I can't be specific about when I'll get time for this. |
Still haven't forgotten! I will get to this as soon as life circumstances permit. |
Still haven't forgotten ... |
My results
|
I have a lateral thinking suggestion to solve this. How about compiling the queries to prepared statements with parameters? That should then execute at full speed on the server. What do you think? |
Pg-simple doesn't supper prepare/execute, does it?
…On 02-Dec-2017 11:47 PM, "tomjaguarpaw" ***@***.***> wrote:
I have a lateral thinking suggestion to solve this. How about compiling
the queries to prepared statements with parameters? That should then
execute at full speed on the server. What do you think?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#347 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AABu0coAAFXet_lZKYE9akmL-GcevMgiks5s8ZQdgaJpZM4QWy3w>
.
|
I don't know but I can't imagine why it wouldn't. Aren't they just standard Postgres commands that (presumably) pg-simple can send? |
Thanks for these excellent benchmark which helped me understand the problem better. It seems clear that the nesting is causing the queries to take hundreds of microseconds longer to execute. I have a couple of problems
At this point I'm not really sure what to do besides discussing with you further how critical this is for your use case and whether we have the possibility of any other workarounds. |
I brought this up-to-date with master on https://github.com/tomjaguarpaw/haskell-opaleye/tree/perf/benchmarks |
Fixes #340