The memory leak is not XCLogParser implementation related, but instead associated with the Scanner object while parsing considerable large files (tested with 243.3MB logs).
The initial attempt replaced Scanner with Substrings (please check commit history). Due to the poor runtime performance, mostly related with protocol witness calls to collection methods, we had to replace with a new Scanner component, implementing a subset of methods for our usages. This new implementation avoids invoking non performance String related methods.
Taking into account the above mentioned file, we were able to improve performance by around 80% compared to masters implementation
This PR fixes the issue #215.
The memory leak is not
XCLogParserimplementation related, but instead associated with theScannerobject while parsing considerable large files (tested with 243.3MB logs).The initial attempt replaced
ScannerwithSubstrings(please check commit history). Due to the poor runtime performance, mostly related with protocol witness calls to collection methods, we had to replace with a newScannercomponent, implementing a subset of methods for our usages. This new implementation avoids invoking non performanceStringrelated methods.Taking into account the above mentioned file, we were able to improve performance by around 80% compared to
masters implementation