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
@david-eckardt-sociomantic mentioned that the buckets themselves can be allocated using the used allocator instead of the GC (e.g when using malloc allocator, the buckets themselves would malloc allocated as well).
For something like the malloc allocator this would give a further performance boost as a map's buckets wouldn't be scanned by the GC (which would yield in faster GC cycles as the GC would have less items to scan).
This is a place holder for the issue so it wouldn't be forgotten.
The text was updated successfully, but these errors were encountered:
Extra suggestion from @gavin-norman-sociomantic was to reduce bucket indices and lengths from size_t to uint. This would limit the number of buckets and items per bucket to 4 billion (32-bits), which I think should be fine for all conceivable future use.
@hatem-oraby-sociomantic :
@david-eckardt-sociomantic mentioned that the buckets themselves can be allocated using the used allocator instead of the GC (e.g when using malloc allocator, the buckets themselves would malloc allocated as well).
For something like the malloc allocator this would give a further performance boost as a map's buckets wouldn't be scanned by the GC (which would yield in faster GC cycles as the GC would have less items to scan).
This is a place holder for the issue so it wouldn't be forgotten.
The text was updated successfully, but these errors were encountered: