Hi everyone,
A couple of days ago I discovered why some people told me that mono-d took about an hour or so just to get finished with “parsing” their libraries – it wasn’t related to “parsing”, it rather was related to the ufcs function pre-analysis. Anyway, mixins and template mixins were the deeper cause for this – and now I improved both parts. The evaluated string will even be cached now until the respective module becomes reparsed. A rip-off from the commit log:
- Implemented a weak reference-based result cache. Solved the inifinite ufcs analysis problems.
- Implemented location-dependent cross-mixin resolution. Mixins can only take mixed-in code from mixins that occur BEFORE the actual mixin statement – in order to prevent infinite resolution pseudo-cycles. Added related test.
- Improved chained concatenation expression evaluation.
- Further tests & checks & null-ref exceptions solved.
A final screenshot to demonstrate stuff that wasn’t possible before the improvements:
Loading ...
3 Comments
Very cool! thanks for you! Love D
Nice work!
Does Mono-D already write caches to disk and reuse those or are caches only kept in memory and regenerated at every application start?
I’m mainly asking because 3rd party libs (druntime, phobos, but also stuff like dyaml, derelict) usually don’t change when developing a project so reparsing them would only be necessary if the time stamps of the source files changed or similar.
Thanks, but no, everything will be generated just at runtime, mainly due to the small amount of time the parser needs to have everything analysed. De-/Serializing entire module bundles from/to a binary format would probably increase the start-up performance again, but well..do you want to write a serializer?