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

Consider removing large, statically allocated module_list #131

Open
reticulatedpines opened this issue Jan 28, 2024 · 1 comment
Open

Consider removing large, statically allocated module_list #131

reticulatedpines opened this issue Jan 28, 2024 · 1 comment

Comments

@reticulatedpines
Copy link
Owner

In module.c we have:

static module_entry_t module_list[MODULE_COUNT_MAX];

MODULE_COUNT_MAX is 64, and a module_entry_t has several char arrays for various module name fields. Total size is 0x2d00, 11kB (see output from: nm --print-size --size-sort --line-numbers magiclantern).

That's a significant cost on the lower memory cams. It would seem more logical if we kept the module info inside each module, and module_list becomes an array of module_entry_t *. We would then avoid paying this large fixed cost when loading ML, instead only paying 1/64th of the cost, per each module, when loaded.

@reticulatedpines
Copy link
Owner Author

Likewise for module_menu, size 0c1600, 5.6kB, due to 64 entries:

1927 static struct menu_entry module_menu[] = {
1928     MODULE_ENTRY(0)

It's less obvious how this gets populated, there's a bunch of horrible macro magic. Still, conceptually, having an array of pointers into modules to get their menus, makes more sense.

It doesn't use MODULE_COUNT_MAX to size this though, just hard-codes 64. So that wants fixing too.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant