Currently, CodeCompass_parser can be parametrized with the -j <N> flag to specify to number of parsing jobs, which could be executed concurrently.
However, for some parsers (e.g. the cpp plugin), it can occur that parsing a translation unit requires large amount (multiple GBs) of RAM. The aim of this issue is to add an additional dynamic guard when starting a new parsing job. In case the available free memory is too low (needs to be specified), then the job shall not be started.
The feature has to be implemented to support both Linux (Ubuntu) and also macOS - related to #637.
In case fetching the free memory is uneasy, as an alternative approach, it would also be valid to measure the allocated memory by the CodeCompass_parser, and enforce an upper threshold based on that value.
Currently,
CodeCompass_parsercan be parametrized with the-j <N>flag to specify to number of parsing jobs, which could be executed concurrently.However, for some parsers (e.g. the
cppplugin), it can occur that parsing a translation unit requires large amount (multiple GBs) of RAM. The aim of this issue is to add an additional dynamic guard when starting a new parsing job. In case the available free memory is too low (needs to be specified), then the job shall not be started.The feature has to be implemented to support both Linux (Ubuntu) and also macOS - related to #637.
In case fetching the free memory is uneasy, as an alternative approach, it would also be valid to measure the allocated memory by the
CodeCompass_parser, and enforce an upper threshold based on that value.