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
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.
The text was updated successfully, but these errors were encountered:
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.
In module.c we have:
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.The text was updated successfully, but these errors were encountered: