Open bigbluejay9 opened 8 months ago
CTRE, as the name implies, only supports compile time regular expressions. Spring mostly uses compile time constant regular expressions, with the key notable exception of globbing: https://github.com/beyond-all-reason/spring/blob/d01542dbad7627dc9a00b3d78e7fee3af7755e30/rts/System/FileSystem/FileSystem.cpp#L40, https://github.com/beyond-all-reason/spring/blob/d01542dbad7627dc9a00b3d78e7fee3af7755e30/rts/System/FileSystem/FileFilter.cpp#L130, https://github.com/beyond-all-reason/spring/blob/d01542dbad7627dc9a00b3d78e7fee3af7755e30/rts/System/FileSystem/FileSystemAbstraction.h#L126.
To use CTRE, we'd have to add support for globbing without regexes - either manually, or pulling in another library, e.g. https://github.com/p-ranav/glob and replacing calls to the real filesystem with calls to VFS.
Other alternative regex libraries:
Is there any heavy regex usage that justifies the cost of additional dependency?
Not that significant, but it is the source of some slowness during loading. ~300ms from sampling (~4% of total load time).
Mainly just investigating what it'll take to switch regex libraries. Even if we don't decide to it might be good to have a trail of what was previously tried.
I think the engine depended on boost at some point, because even the mention of it gives me ptsd.
I like the CTRE + https://github.com/p-ranav/glob idea.
Spring uses the std::regex library to perform regular expression operations.
std::regex is known to be quite slow https://github.com/HFTrader/regex-performance#results with potentially no path forward to improve its performance stack overflow, llvm discussion.
Spring has minimal dependencies on the std::regex library, which is exposed through https://github.com/beyond-all-reason/spring/blob/BAR105/rts/System/SpringRegex.h by re-exporting the std::regex* symbols.
Investigate replacing std::regex with a more performant library. Doing this when there are few dependencies should make the work somewhat more straightforward.