Add option for stacktrace filling - #245
Conversation
|
I am not sure the added config complexity is worth it for this. Unless you are creating millions of pools, the performance impact of this is trivial. This code is run only once, when the pool is created. I am afraid that users would end up confused into thinking this was about pooled objects - basically needless cognitive load for 99.99% of users. |
|
Closing, see above. |
|
I'll try to explain why this is required. Some database have transactions; in transactions, entities are created that can be reused in case of multithreading (cursors). To minimize the number of cursors (and their creation), a pool of objects is used In the case of a large number of transactions, the cost of initializing the stack trace becomes noticeable. The external pool is not convenient to hold, because its lifetime is equal to the transaction lifetime Benchmark result (https://gist.github.com/mad/91e7b587cd7677ef04139d805219e318) Profiling |
Currently stacktrace filled by default but sometimes it is useless and affect on performance