Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

make auto allocators optional #1

Open
electronstudio opened this issue May 17, 2024 · 3 comments
Open

make auto allocators optional #1

electronstudio opened this issue May 17, 2024 · 3 comments
Labels

Comments

@electronstudio
Copy link
Owner

make sure advanced users have option to specify their own allocators to improve performance - the auto ones should not be mandatory anywhere

@electronstudio
Copy link
Owner Author

for constructors and raylib functions that allocate you can now specify your own arena allocator. the only auto arena is when converting string arguments to function calls. i guess this should be replaced by:

if function call is one that has string arguments:

  • if no arena supplied, then create a local arena, do function call, then destroy it (i.e. try with resources) (but is this any quicker than just using an auto arena that goes out of scope? i doubt it)
  • elif arena supplied, use it. (but in most cases this would not be what the user should do because memory isnt freed, unless performance of creating arena is problem.)

performance impact of all this is probably so tiny it's not a priority

@electronstudio
Copy link
Owner Author

The auto arena for string arguments does actually reduce bunnymark by 4000 when using DrawText()!

Another alternative: allocate temp memory once on startup and then re-use it. not threadsafe. might need custom arena/allocator or something.

@electronstudio
Copy link
Owner Author

local arena for string arguments done

@electronstudio electronstudio changed the title TODO: make auto allocators optional make auto allocators optional May 21, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant