RAM Usage on Embedded System – Advice Needed on Optimization

[sylque]

Hi @Blake-Madden,

I'm working with the library on an embedded system and running into RAM usage issues. I’m looking for guidance on whether to submit feature requests or pursue internal customizations to reduce memory consumption.

Context

• System constraints: Embedded environment with limited memory
• Usage pattern:
  • ~100 simultaneous pre-compiled expressions (te_parser instances)
  • Most expressions are simple (often just a single variable)
  • Each expression is initialized with ~50 variables (each typically uses only 1–2, but it's not known in advance which ones)

I’m already using TE_NO_BOOKKEEPING, but I’m still seeing significant heap usage. My current assumption is that much of this comes from storing variable names (in m_customFuncsAndVars and possibly elsewhere). For example:

100 expressions × 50 variables × ~8 bytes per name = ~40 KB of heap used for variable names alone

Questions

1. Is this analysis accurate?
   Are all variable names stored for each expression, regardless of usage? Are those names still needed for evaluation after compilation?

2. Can variable names be freed after compilation?
   I tried calling expression.set_variables_and_functions({}) post-compilation, but then of course evaluation fails as this removes all te_variable instances, not only names.

3. Is there a way to remove unused variables post-compilation?
   I'm considering enabling bookkeeping, then using is_function_used() and remove_variable_or_function() to prune unused variables after compilation. Is this a viable approach?

Any insight or suggestions would be greatly appreciated!

Thanks,
Sylvain

[Blake-Madden]

I'll take a look at it this week. At the very least I could try using PMR; it looks like Apple-Clang finally supports that. It may not entirely fix the memory footprint, but would at least get rid of a lot of heap thrashing.

[sylque]

My issue is resolved for now: removing unused variables after compilation turned out to be very effective, saving me dozens of kilobytes of heap memory.

Here’s the code I used:

    // Add all variables to the expression: this stores all variables in the
    // te_parser, even those that will not be used.
    const std::set<te_variable> teVars = buildTeVariableList();
    m_parser.set_variables_and_functions(teVars);

    // Compile the expression
    const bool res = m_parser.compile(expressionString);

    // In case of error...
    if (!res) {
      // Free the heap
      m_parser.set_variables_and_functions({});
      m_parser.compile({});
      return false;
    }

    // Remove unused variables from the parser. This frees a lot RAM.
    for (const auto& teVar : teVars) {
      if (!m_parser.is_variable_used(teVar.m_name)) {
        m_parser.remove_variable_or_function(teVar.m_name);
      }
    }

This optimization might be worth integrating directly into the library.

As a possible future direction, if I run into RAM issues again, I may look into whether variable names really need to be kept after compilation—or if discarding them could free up even more memory.

[Blake-Madden]

Are you only wanting to call compile() once? I ask, because once you remove all custom variables and functions, then the next call to compile() will no longer support them.

In your scenario, if the client enters invalid syntax, then all your customs vars will be cleared and when they try the formula again it won't work as expected. And if they enter a valid formula, then only the vars they used in their initial formula will survive. If they try another formula, then a lot of the custom vars and funcs from before will no longer be there. Is that the intention?

[Blake-Madden]

I just added remove_unused_variables_and_functions(), so your example could be done like this now:

    // Add all variables to the expression: this stores all variables in the
    // te_parser, even those that will not be used.
    m_parser.set_variables_and_functions(buildTeVariableList());

    // Compile the expression
    const bool res = m_parser.compile(expressionString);

    // In case of error...
    if (!res) {
      // Free the heap
      m_parser.remove_unused_variables_and_functions();
      m_parser.compile({});
      return false;
    }

    // Remove unused variables from the parser. This frees a lot RAM.
    m_parser.remove_unused_variables_and_functions();

Most important is the first line:

m_parser.set_variables_and_functions(buildTeVariableList());

By not needing to store the teVars variable, move semantics should kick in and lower the RAM usage even more. Please let me know if this helps.

[sylque]

Please let me know if this helps.

Excellent, thanks a lot, I will try this now.

Are you only wanting to call compile() once?

Yes I am.
I compile expressions exactly like I would compile a program.

My naive perspective is that:

"Expression string" + "variable list" => "compiled expression"

Thus:

• The "compiled expression" should retain neither the original "expression string" nor the "variable list". It should only retain pointers on a few of the variable values.
• In that scenario, when you need to recompile an expression, you'd need to supply both the "expression string" and "variable list" again.

[sylque]

remove_unused_variables_and_functions() seems to work like a charm.

Thanks for pointing out the missing move semantic. Incorporating that indeed reduces peek memory usage.