Looks like there is a lock for get thumbnail for different presentations, my logic is simple, just receive pptx file, and convert to thumbnails, then return to website. I use write a multiprocessing in python to requests this api, it cannot be handled in multi-threading mode.
When I export same presentation in memorystream from bytes to thumbnails, in multi threads, it will not render each presentation in parallels.
eg,
1 thread, each presentation takes 2.5s
2 thread, each presentation takes 4.2s
10 thread, each presentation takes 6.2s
Why each presentation not same time, it should be ~2.5s, because I run them in parallels.
Even I have 32 core CPU, it will not render thumbnail in each threads separately, when deep look into Timeline Profile, I noticed there is a lock when get thumbnail from Slide. I guess, maybe GetThumbnail is locked in code, even if I run in threads.
@islide,
Thank you for the information. I’ve reproduced the problem you described.
We have opened the following new ticket(s) in our internal issue tracking system and will deliver their fixes according to the terms mentioned in Free Support Policies.
Issue ID(s): SLIDESNET-44389
You can obtain Paid Support Services if you need support on a priority basis, along with the direct access to our Paid Support management team.
Please also share the following additional information if it is possible:
The issues you found earlier (filed as SLIDESNET-44389) have been resolved in Aspose.Slides for .NET 25.3 (ZIP, MSI, NuGet, Cross-platform).
You can check all fixes on the Release Notes page.
You can also find the latest version of our library on the Product Download page.
@islide,
We have fixed an issue related to static locking in multithreaded mode during image generation.
The image generation time per thread has been reduced from approximately 270% to 180% when running eight threads simultaneously compared to single-threaded execution.
Performance Comparison
1 thread:
8 threads after lock optimization:
8 threads before lock optimization:
Approximately 80% of the remaining time is spent on GC Wait operations (50%) and overhead (30%) caused by increased contention for shared resources.
The time spent on GC Wait operations (thread blocking during GC calls) can be reduced by switching GC to server mode. We found that GC in workstation mode (e.g., the default in console applications) is less effective for multithreading.
After switching GC to server mode, the image generation time was further reduced from 180% to 130% when running eight threads simultaneously:
To enable server GC mode, add the following tag to the section in the .csproj file:
Sets consent for sending user data to Google for online advertising purposes.
Sets consent for personalized advertising.
Cookie Notice
To provide you with the best experience, we use cookies for personalization, analytics, and ads. By using our site, you agree to our cookie policy.
More info
Enables storage, such as cookies, related to analytics.
Enables storage, such as cookies, related to advertising.
Sets consent for sending user data to Google for online advertising purposes.
Sets consent for personalized advertising.
Cookie Notice
To provide you with the best experience, we use cookies for personalization, analytics, and ads. By using our site, you agree to our cookie policy.
More info
Enables storage, such as cookies, related to analytics.
Enables storage, such as cookies, related to advertising.
Sets consent for sending user data to Google for online advertising purposes.