-
-
Notifications
You must be signed in to change notification settings - Fork 99
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Significant slowdown on nested tables depending on syntax #193
Comments
The former performs a lot of table merging when parsing, while the latter is a single table with plain table keys. |
Yes, but seems the number of such mergings grows exponentially with input size. Looking into the profiler output we can see millions of calls for reading only 12 values.
|
@frostming or others, could I ask what are the chances of fixing this soon? I'm getting six minute(!) runtimes parsing a toml file. See #319. It's a problem so serious that I will have to switch to a different library soon if a fix will not be coming. The workaround of switching from dotted keys to dotted groups doesn't work on my case because I need to be able to sort the toml file, so each key-value pair needs to be context-free, and groups prevent that. There are other ways to handle merging tables that don't require exponential growth. I'm happy to try to help, if needed. If you could point me to the place in the code that does this I could take a look. |
I won't be able to in the short term, or you can try researching it yourself. I would be happy to review. The parsing logic is a bit convoluted for such a style-preserving TOML library. I wonder if switching to a non-style parser like |
Fixes #193 Signed-off-by: Frost Ming <me@frostming.com>
Reading TOML files with nested tables with same meaning, but different syntax makes a big difference in speed. Using full names is much slower (~300x on my machine) than using square brackets for common part:
The text was updated successfully, but these errors were encountered: