I have a question about performance, and this is not a complaint, just trying to understand some things.
If I run the FullDemo that comes with the Editor SDK(to eliminate the possibility the problem was in my program) and load approximately 350ish documents with a total combined size of around 50MB the application seems to begin to have severe performance issues and becomes unresponsive.
This is not exactly unexpected as the number of documents is incredibly large, but I noticed the only performance metric controls under the preferences menu have to do with memory(in MB or %) to limit the application and some threading restrictions.
So a few questions:
1.) is there a "maximum" document count you would recommend having open at a single time? At what point does it become a problem as the machine I am currently on(8 cores, 16GB ram, all SSD) is experiencing issues at the above thresh-hold but the entire full demo application is only using about 400MB of memory, well below the 25% limit I set but it is still unresponsive
2.) Is there a best practice you'd recommend for limiting the number of simultaneous documents? I had previously used your controls based on % of available memory but these fringe cases slip through the cracks. Is the number of open docs tied to something else I can scale off of? Obviously I just put a setting in my own app saying once X number of documents are open stop opening and do something else, but wanted to check in here if Tracker or others have seen this issue and how they dealt with it.
The application seems to do very well opening small amounts of large files, but not large amounts of small files. I am not trying to call it a bug, just looking for some general guidance or best practices.
Large Document Count Performance
Moderators: TrackerSupp-Daniel, Tracker Support, Paul - Tracker Supp, Vasyl-Tracker Dev Team, Chris - Tracker Supp, Sean - Tracker, Ivan - Tracker Software, Tracker Supp-Stefan
Forum rules
DO NOT post your license/serial key, or your activation code - these forums, and all posts within, are public and we will be forced to immediately deactivate your license.
When experiencing some errors, use the IAUX_Inst::FormatHRESULT method to see their description and include it in your post along with the error code.
DO NOT post your license/serial key, or your activation code - these forums, and all posts within, are public and we will be forced to immediately deactivate your license.
When experiencing some errors, use the IAUX_Inst::FormatHRESULT method to see their description and include it in your post along with the error code.
-
Roman - Tracker Supp
- Site Admin
- Posts: 303
- Joined: Sun Nov 21, 2004 3:19 pm
Re: Large Document Count Performance
Hi DolphinMann,
This is most probably because SDK FullDemo is a 32-bit application. 32-bit application is limited not only in total available memory.
Multiple opened ducuments make application memory highly fragmented and limit contiguous memory chunk size that could be allocated. This in its turn might cause heavy file swapping, object re-creation and so on - all these contribute to the performance degradation.
To deal with so many documents you need to build a 64-bit application.
This is most probably because SDK FullDemo is a 32-bit application. 32-bit application is limited not only in total available memory.
Multiple opened ducuments make application memory highly fragmented and limit contiguous memory chunk size that could be allocated. This in its turn might cause heavy file swapping, object re-creation and so on - all these contribute to the performance degradation.
To deal with so many documents you need to build a 64-bit application.