Optimise ROTable accesses and interface #2505
Conversation
| unsigned hash; | ||
| unsigned addr:24; | ||
| unsigned ndx:8; | ||
| } cache[LA_LINES][LA_SLOTS]; |
There was a problem hiding this comment.
Eeep! That's half a K right there, isn't it? :(
Could this be an optional feature, so those really tight on RAM can opt for the performance hit instead?
There was a problem hiding this comment.
That was the ½K
I'll also do the claw- back on DNS on this patch so we don't lose net RAM.
There was a problem hiding this comment.
No don't make it dynamic. This is something which if it's in use, it should be statically allocated to ensure it's there when needed. Plus it makes it easier to reason about other RAM usage.
If you can reclaim RAM from elsewhere so the net available stays the same, that would be Very Good :) And if half the size is enough for the common scenarios, that sounds good too!
| /* | ||
| * The invariants for 1st word comparison are deferred to here since they | ||
| * aren't needed if there is a cache hit. Note that the termination null | ||
| * is included so a "on\0" has a mask of 0xFFFFFF and "a\0" has 0xFFFF. |
|
@jmattsson, the lookaside cache seems to work well. "How big should we make it" is a useful Q to ask. 8 x 4 seems to be a good compromise, and most real life Lua applications rarely use anything like 32 ROTable fields, so the hit rates should be pretty good -- in the 99% ballpark, which effectively eliminates the search overhead for normal field access. We still have this issue of cases where the VM does existence checks for fields such as |
Some refinements to the ROTable cache which remove the linker cludges on the CROSS_COMPILE builds. Also keyhole tweaks to some of the Lua VM code to implrove runtimes. I also noticed some compile time warnings during the build; the change to uz_unzip.c doesn't impact the compiled code, but does remove the compiler warnings.
Addresses Issue #2504
devbranch rather than formaster.See #2504 for detailed discussion of the background and scope of this patch. There isn't any change at an application level, apart from making ROTable access times comparable to RAM Table access times. The code changes therefore don't impact the documentation at
docs/en/*excepting the following points:pairs(_G.__index).