New feature: Cache grammars for fast initialization of Lark
See original GitHub issueThis is straight-forward, and such a feature already exists in PLY, for example. This would be especially beneficial for LALR.
It should be fairly easy to write, since the Lark
class already supports serialization and deserialization. All that’s required is to add an interface for saving/loading it to some temporary file.
Issue Analytics
- State:
- Created 4 years ago
- Reactions:3
- Comments:13 (8 by maintainers)
Top Results From Across the Web
API Reference - Lark documentation
Cache the results of the Lark grammar analysis, for x2 to x3 faster loading. ... A List of either paths or loader functions...
Read more >grammar files get opened an unnecessary amount of times, causing ...
Parsing the lark grammar is done using LALR, so unless it's thousands of lines, ... cache=True for the whole lark instance should be...
Read more >Working with the feature cache—ArcMap
The feature cache allows you to temporarily store the features in the current map display in ArcMap in your local machine's memory. Because...
Read more >Untitled
Safeauto quick pay, Desneymovies full movie frozen, Vickerman twig christmas ... First travel manchester, Parkway drive new album, Grace carney violin, ...
Read more >Assume x1 and x2 in same cache block. P1 and P2 both read ...
Implementing Snooping Caches. Multiple processors must be on bus, access to both addresses and data; Add a few new commands to perform coherency,...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
It would be important to include the lark version inside the hash to make sure that lark doesn’t try to load an incompatible parser.
Another set of values is also possible, and perhaps preferable:
cache=False will disable cache
cache=True (default) will use a temporary file selected by Lark, based on hash
cache=“filename” will use that path for saving the file, still considering hash to prevent versioning issues (Also accepts Path objects).
Do you think the first is better, or this one?