Optimization Problems on Dev Branch

[RapperGF]

In the development branch the VM uses MemberResolver which is a nice saftey wrapper around the old way of getting members but introduces a performance regression.

Accessing Native Object fields is known to be expensive due to the use of Dynamic which on static targets is extremely slow. On the main branch the performance expected is around 10 thousand entitles with 6 property sets per frame at around 30 fps.

MemTest_2026-03-14_23-51-55.mp4

On the dev branch this same test leads to a not responding window or very low framerate.

MemTest.2026-05-05.00-53-47.mp4

I did some digging to find the culprit and its due to var instanceFields:Array<String> = nativeClass == null ? null : Type.getInstanceFields(nativeClass);

On native targets such as hxcpp this function is ran in the hot loop scanning every field of the class essentially bottlenecking the VM.

I recommend we either attempt to cache the instanceFields or remove it from MemberResolver.

[RapperGF]

MemTest.2026-05-11.21-26-56.mp4

Newest Commit 780ad42

[RapperGF]

Update

I profiled the cycles of the current Commit 851b4a8

hit a max of 15-17 frames

And I knocked it down with some experimental changes and reverting some code including MemberResolver. down 10-18% of the current hotpaths

Results:

MemTest.2026-05-12.01-53-21.mp4

Just barely shy of current Main Branch in actual time spent on the main run function

[RapperGF]

@senioritaelizabeth if these changes prove stable I think the regression is gone.

There's still a lot of things biting the true speed of the VM such as the Run Function body, unboxing enum values, map getting/setting and dynamic itself but this brings us much closer to where we were.