Skip to content

Updated benchmark to use pooling#1

Merged
usercode merged 1 commit intousercode:mainfrom
MarkCiliaVincenti:AsyncKeyedLockPooling
Feb 6, 2023
Merged

Updated benchmark to use pooling#1
usercode merged 1 commit intousercode:mainfrom
MarkCiliaVincenti:AsyncKeyedLockPooling

Conversation

@MarkCiliaVincenti
Copy link
Contributor

The way you are benchmarking currently doesn't cater for multi-threading or contention. I didn't want to change such tests; however, I did amend the benchmark for my library to use the pooling (which by default is disabled) and you will be able to notice the big difference in the memory allocations.

@usercode usercode merged commit c8bd982 into usercode:main Feb 6, 2023
@usercode
Copy link
Owner

usercode commented Feb 6, 2023

Yeah, I will add more benchmarks later.

After enabling the pooling, AsyncKeyedLock is slower than ImageSharpWeb. I think the main reason for pooling is to get a better performance and not to reduce memory. That's why all frameworks enable this feature per default.

@MarkCiliaVincenti
Copy link
Contributor Author

Yeah, I will add more benchmarks later.

After enabling the pooling, AsyncKeyedLock is slower than ImageSharpWeb. I think the main reason for pooling is to get a better performance and not to reduce memory. That's why all frameworks enable this feature per default.

The main reason for the polling in AsyncKeyedLock is to reduce memory allocations. In the benchmarks I did, it also improved performance.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants