Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.
And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.
Performance issue
See original GitHub issueWe have encountered a very similar issue however even the latest (3.4.5) version doesn’t seem to fix this. It has improved but it’s not on the same level as before. Our situation is the following, we upgraded from 2.9.0 to 3.1.6 and noticed that the memory usage of our application was quite a bit higher then before.
So i setup a small console project that executes an update command on an in memory SQLite database (link to repo), and added some benchmarking library.
Not only is the memory usages in 2.9.0 much better, the performance is also quite a lot better. These are the result when run on my machine:
3.4.5
| Method | Mean | Error | StdDev | Gen 0 | Gen 1 | Allocated |
|---|---|---|---|---|---|---|
| Small_UpdateStatement_With_Variable_Parameters | 7,148.1 us | 105.17 us | 121.11 us | 93.7500 | 62.5000 | 414 KB |
| Small_UpdateStatement_With_Static_Parameters | 183.0 us | 2.94 us | 3.27 us | 5.3711 | - | 22 KB |
| Large_UpdateStatement_With_Variable_Paramters | 25,341.0 us | 483.85 us | 557.20 us | 125.0000 | - | 922 KB |
| Large_UpdateStatement_With_Static_Paramters | 293.6 us | 4.63 us | 4.96 us | 8.7891 | - | 36 KB |
| Large_UpdateStatement_With_Variable_Paramters_With_ClearCaches | 19,227.3 us | 1,071.55 us | 1,234.00 us | 62.5000 | 31.2500 | 298 KB |
3.1.6
| Method | Mean | Error | StdDev | Gen 0 | Gen 1 | Allocated |
|---|---|---|---|---|---|---|
| Small_UpdateStatement_With_Variable_Parameters | 11,831.9 us | 176.45 us | 188.80 us | 140.6250 | 62.5000 | 675 KB |
| Small_UpdateStatement_With_Static_Parameters | 245.3 us | 31.17 us | 35.90 us | 6.1035 | - | 25 KB |
| Large_UpdateStatement_With_Variable_Paramters | 38,473.9 us | 2,112.70 us | 2,260.57 us | 312.5000 | - | 1,593 KB |
| Large_UpdateStatement_With_Static_Paramters | 326.5 us | 5.19 us | 5.33 us | 9.2773 | - | 39 KB |
| Large_UpdateStatement_With_Variable_Paramters_With_ClearCaches | 16,906.5 us | 263.30 us | 303.22 us | 93.7500 | 31.2500 | 403 KB |
2.9.0
| Method | Mean | Error | StdDev | Gen 0 | Gen 1 | Gen 2 | Allocated |
|---|---|---|---|---|---|---|---|
| Small_UpdateStatement_With_Variable_Parameters | 2,386.7 us | 34.38 us | 39.59 us | 50.7813 | 15.6250 | 3.9063 | 248 KB |
| Small_UpdateStatement_With_Static_Parameters | 169.0 us | 6.39 us | 6.83 us | 4.8828 | - | - | 21 KB |
| Large_UpdateStatement_With_Variable_Paramters | 5,290.6 us | 43.50 us | 46.55 us | 125.0000 | 7.8125 | - | 567 KB |
| Large_UpdateStatement_With_Static_Paramters | 264.9 us | 8.48 us | 9.43 us | 7.8125 | - | - | 33 KB |
| Large_UpdateStatement_With_Variable_Paramters_With_ClearCaches | 1,999.7 us | 24.64 us | 26.36 us | 35.1563 | 11.7188 | - | 151 KB |
The thing is that when the update statement contains the same values in the set (in other words set(columnname, value)), there seems to be no problem. It is only when the value changes that the issue arises.
When analysing the problem with dotMemory, you can see that there are a lot of QueryCacheEntry<TESTTABLE> objects in memory, while in 2.9.0 this is not the case (I don’t think QueryCache<T> was a thing in 2.9.0).
This memory snapshot is after executing Large_UpdateStatement_With_Variable_Paramters 200 times.
3.1.6
Also the sql text of the update is saved in memory a hundred times:
This seems a bit weird to me.
2.9.0
The weird part to me is how 2.9.0 seems to use less memory and is more performant. It would be ok if 3.1.6 had higher memory usage but the queries were faster. But this isn’t the case. Also adding Query.ClearCaches after the update statement seems to improve the performance and the memory usage, this to me indicates that something is wrong.
_Originally posted by @aarondk-dev in https://github.com/linq2db/linq2db/issues/2556#issuecomment-940080728_
Issue Analytics
- State:
- Created 2 years ago
- Comments:14 (10 by maintainers)
Top Results From Across the Web
Top Related Medium Post
Top Related StackOverflow Question
Troubleshoot Live Code
Top Related Reddit Thread
Top Related Hackernoon Post
Top Related Tweet
Top Related Dev.to Post
Top Related Hashnode Post
Good news. Looks like in next release we will have huge improvement here. I’ve managed to fix mentioned issue with Set and already got huge perf/memory bust. Still need to check other APIs for similar issues and check if there is more space for fixes.
I’m sorry I made a mistake, it is indeed fixed, my apologies.
PR: