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
When we read RPG_RT.ldb we can read the chunk sizes and actually compute the entire size layout of the database.
Read the chunk sizes of the database to quickly determine the maximum size of the entire RPG::Database.
Perform a single call to operator new() to allocate the entire database.
Layout the data structures onto this single memory allocation. Objects used frequently together in time should be laid out similarly in space.
This would result in the most optimal memory layout possible for the entire database. This would surely produce a measurable increase on frame rates and battery life on mobile devices for Player.
The locality improvements and removal of all memory allocations except one should produce significant performance improvements in reading and writing in liblcf.
This will be perfect for player, but tricky for editor.
In editor you want to do more like you would with vectors. So you can resize things. If you had to reallocate the enitre database every time you changed the size of something in Editor, it would be slow and kill the interactivity.
So for editor we'd have to grow our allocation vector style, and amortize the cost of reallocations to keep the editor gui running interactively.
The text was updated successfully, but these errors were encountered:
mateofio
changed the title
Custom memory allocator for the RPG_RT.ldb database
Custom memory allocator for RPG::Database
Oct 5, 2018
When we read
RPG_RT.ldb
we can read the chunk sizes and actually compute the entire size layout of the database.RPG::Database
.operator new()
to allocate the entire database.This would result in the most optimal memory layout possible for the entire database. This would surely produce a measurable increase on frame rates and battery life on mobile devices for Player.
The locality improvements and removal of all memory allocations except one should produce significant performance improvements in reading and writing in liblcf.
This will be perfect for player, but tricky for editor.
In editor you want to do more like you would with vectors. So you can resize things. If you had to reallocate the enitre database every time you changed the size of something in Editor, it would be slow and kill the interactivity.
So for editor we'd have to grow our allocation vector style, and amortize the cost of reallocations to keep the editor gui running interactively.
The text was updated successfully, but these errors were encountered: