Closed kLabz closed 1 month ago
Nice, this check works :)
Edit: and after setting development
as base branch:
:ok_hand:
This is neat, it's nice that we can do something like that now. Having a two-layer cache like this makes sense to me because we separate the properly cached data from the working data, which should also give a good memory layout for the GC.
I'll have to review the server.ml changes more in-depth because at the very least they duplicate some code.
Also I find reset
to be a misleading name for something that merely clears the temp cache.
Yeah, that's something I wanted to do pretty much since the beginning but wasn't working well on previous attempts, needed that separate "working data".
Right, I cleaned up a bit, hope it's better like that!
Built on top of #11659 for nowbinary_cache
incompilationCache.ml
)MSGood
during display requestsI tested this branch with all projects I had available, without detecting any issue (at least not any new issue) and got very promising results (see below).
Notes:
hxbit
letting it run its macros during display requests (but that's also true for other nightlies)[Shiro project]
5.0.0-alpha.1+c325889
:[Shiro project]
5.0.0-alpha.1+c325889
:[Shiro project]
5.0.0-alpha.1+c325889
:[Personal heaps game] (very similar results on other small[ish] scale projects)
5.0.0-alpha.1+c325889
:Other "small scale" projects
Smaller projects that tend to have no issues with Haxe 4 and are running diagnostics still have much faster display requests when cache has just been filled (after compilation or diagnostics), though even those can have slightly better timings (with diagnostics disabled at least) when files start to be invalidated.
Misc
5.0.0-alpha.1+c325889
and this branch ~15sec including 12+ seconds of macros and rest in typing; something is wrong on user code there