Slowness when using large number of dynamic parameters
Nobody has claimed this yet.
- Dominant language
- C#
- Stars
- 18.4k
- Forks
- 3.7k
- Avg merge
- 5h 8m
- Merged PRs (30d)
- 1
Description
When using a large number of query parameters, Dapper appears to take an extremely long time to add the parameters to the command before executing it. It took ~40 seconds to add 11k parameters.
I verified it was not an issue with casting or the query itself by grabbing the plan explanation for the query out of the logs. (I am using Postgres and used the auto explain module to generate it, which hopefully removes .) Running the query directly on the database executes fairly quickly (< 1 second)
I also used the debugger to verify it was an issue with Dapper itself - it looks like the majority of time is spent in the AddParameters method in the DynamicParameters class.
I also tested out explicitly specifying the db type of the parameter (DbString), as well as the length and input direction, but that did not seem to have any significant effect on the performance.
I do have a workaround, as this particular query can be split up into batches, I but just wanted to verify that this a limitation of Dapper, and make sure there isn't a different way to approach the problem.
Edit: Forgot to mention, I'm seeing this behavior with version 2.0.35.
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with DynamicParameters.AddParameters and reproduce the reported case of adding 11k parameters on PostgreSQL with Dapper 2.0.35. Profile the parameter-building path before query execution and determine whether the behavior is a fixable performance problem or a limitation; document the cause and expected behavior, with regression coverage if a fix is identified.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- csharp, postgresql
- Domain
- database
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 35/100