DapperLib / DapperLib/Dapper

Slowness when using large number of dynamic parameters

Open
#1,537 2 comments 1 reaction 0 assignees View on GitHub

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

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.