hello
Am considering some macro / calm inx where i might be needing to construct polynomials with a significant number of variable terms.
Should I consider some limitations reg. max number of variable terms to allow ?
Empirically, i tried with very simple snippet below


setting various CNT value
* 256 variable terms => seems to work fine
* 1024 variable terms => seems to work fine
* 2048 variable terms => seems to work fine
* 4096 variable terms => starting to see perf degradation
* 8192 variable terms => perf degradation noticeable

Tomasz, can u give some tech insight ?? Am I going too crazy here ?

As a sidenote, I feel that with the very high flexibility that famsg offers - which is actually a very good thing, making it a very powerful tool for sure - definitely appreciable - sometimes am finding myself wondering about which impl. option i should favor (or dismiss..) to implement some ideas, that am pondering...
More often than not, it seems to me, some more details regarding the internals of fasmg would help pointing me in the right direction...
typ. :
* how costly is a variable / symbol
* should i consider restoring after use or not (prev discussions seem to indicate that it is not necessary and even potentially counter-productive perf/memory -wise)
* should I favor multiple variable creation or rather use a virtual area to store working data
* how costly is it it terms of perf /mem to re-open virtual areas multiple times, to feed data through...
* ....

... reg the above, i fully understand that exec time is a factor of CNT, but just to understand if sthg else can be at play here reg perf / mem. management of fasmg.

The linear polynomials as implemented in fasmg were not optimized to handle more than a couple of terms efficiently. I was implementing it with expressions like "IMAGE_BASE+ebx*8+ecx" in mind, not a thousand term monstrosities. It it actually impressive that even with 2048 it seemed to work fine for you - if I had to guess, I would not expect it to work well.

Well, as they* say: the only real way to find out is to test it.
___
* revolution, probably.

... some other questions that came to mind :
* is it better perf/mem wise to create as many variables as values i need to store, or better to stack values in a single variable ?
* reg variable vs virtual usage : how much diff perf & mem-wise in terms of access regarding doing sthg like V = V + 1 vs. load V:4 from Area:offset then store (V+1):4 at Area:offset - what about calm (compute V, V+1 vs similar load/store combination) ?
* impact on perfs / mem of nb and complexity of namespaces (nb of symbols, symbols length, nesting levels) ?

That was my very first thought when I saw the questions.

... thanks for the above f/b ... in line with my intuition .. indeed testing is key (fact checking so to speak)
.. but sometimes knowing about internal tech design can also help / give colour

Have you tried to browse the actual source code? What I could do is perhaps adding more technical explanations in the comments (the ones that are there currently are mostly focused on my own needs, reminding me of various caveats).