You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm seeing some semi-expensive luaH_getn invocations on the registry a la lua_ref. It seems like aboundary is being used by the hashtable, causing the VM to continuously find the array boundary again. Stepping through it in a debugger, it looks like t->aboundary/t->lastfree is always 1.
This has little impact except where lua_ref is in a hot path. Unfortunately, this means a lot of binding layers are impacted.
VTune Call Tree in a simple benchmark program:
Callers Effective Time Spin Time Overhead Time Effective Time Spin Time Overhead Time Wait Time: Total Wait Time: Self
[Loop at line 781 in luaH_getn] 100.0% 0.0% 0.0% 637619.390usec 0usec 0usec
luaH_getn 100.0% 0.0% 0.0% 637619.390usec 0usec 0usec
lua_ref 100.0% 0.0% 0.0% 637619.390usec 0usec 0usec
The text was updated successfully, but these errors were encountered:
Hi,
I'm seeing some semi-expensive
luaH_getn
invocations on the registry a lalua_ref
. It seems likeaboundary
is being used by the hashtable, causing the VM to continuously find the array boundary again. Stepping through it in a debugger, it looks liket->aboundary
/t->lastfree
is always 1.This has little impact except where
lua_ref
is in a hot path. Unfortunately, this means a lot of binding layers are impacted.VTune Call Tree in a simple benchmark program:
The text was updated successfully, but these errors were encountered: