Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Continuing the ceify journey.
Fixes #470
this replaces the lua implementation of the
metro
lib with a C based one. there's still a little lua stub file which does the linking because i just wanted to get it in and tested. could save a little more RAM by doing the assignments in C, but this feels like a good place to leave it and move on to bigger fish.increases the FLASH usage by 60bytes
decreases runtime RAM usage by 2.85kB (current runtime is 90.6kB at launch)
not a lot of a benefit really (especially bc it took me 6+ hours though most of that was airplane brain), but it is a solid 6% relative to the logical minimum (about 45kB).
//
i'm realizing the big benefit to come from these routines is not so much about shrinking the amount of lua code that is loaded into the runtime, but rather about reducing the amount of dynamic allocation happening as a result of using the libraries.
going forward, i'm going to focus on libraries that allocate lots of data when you use them (sequins, clock, asl). i think
clock
is the biggest culprit as creating and pause/resuming a bunch of coroutines is i think quite heavy on the runtime.come to think of it, i should do some analysis of what is causing the ram usage. forthcoming...
//
but for now, this feels like a solid inclusion & all of the documented usage in the reference is working correctly in my testing.
// EDIT
after a little further testing, it seems that the
clock
library is just fine churning through garbage. the collection routinely brings usage back down to ~95kB as a number of simultaneous clocks are banging away.going to move on to re-introducing the timeline library and see if i can recreate the issues i was experiencing which sent me down this path many moons ago...