You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
It will be nice to improve the performance of the Qualification/Profiling tools.
The tools can easily run out of memory as the implementation keeps everything in the memory. Then finally dumps the report. This was mainly the case at the early development phases when the tools was generating the formatted output or pick some statistics across different applications.
This is probably not needed anymore as we can offload some of the cross-app to the user-tools wrapper. Furthermore, we can just separate the cross-app module to consume the raw data. This way we don't have to keep everything in the memory
Currently, we don't have a performance-profiler that lists the memory/CPU consumption of the code blocks.
This issue is filed to keep track of reports related to performance and possible areas of performance
Describe the solution you'd like
We need to:
Break-down of the time/memory consumption to identify the bottlenecks.
IMHO (@amahussein) the tools is memory bound and it is unlikely that CPU is highly utilized.
For large eventlogs, the tools might trigger frequent Full GCs which are characterized by long pause-times.
Enumerate areas that can be improved by multithreading.
It will be a set of configurations to the CLI that improves the execution of the tools. For example,
tools running on CSP, then we should recommend users to configure clusters with high memory capacity.
For JVM commands, ideal heap size and GC configuration.
The content you are editing has changed. Please copy your edits and refresh the page.
Is your feature request related to a problem? Please describe.
It will be nice to improve the performance of the Qualification/Profiling tools.
The tools can easily run out of memory as the implementation keeps everything in the memory. Then finally dumps the report. This was mainly the case at the early development phases when the tools was generating the formatted output or pick some statistics across different applications.
This is probably not needed anymore as we can offload some of the cross-app to the user-tools wrapper. Furthermore, we can just separate the cross-app module to consume the raw data. This way we don't have to keep everything in the memory
Currently, we don't have a performance-profiler that lists the memory/CPU consumption of the code blocks.
This issue is filed to keep track of reports related to performance and possible areas of performance
Describe the solution you'd like
We need to:
Tasks
The text was updated successfully, but these errors were encountered: