clipka <ano### [at] anonymousorg> wrote:
> Am 24.05.2018 um 10:04 schrieb Kenneth:

> > From this, it makes me wonder if the bulk of the parse-time-speedup is in
> > mesh2 meshes and/or trace...
>
> There is no speedup to be expected in the trace() function, nor is there
> any speedup to be expected in mesh2 /per se/.
>
> Just as a hunch, does your loop invoke any macros?
>
> If so, it's fundamentally different from Stephen's loop: The latest
> v3.8.0-x.tokenizer version can execute his loop from memory without
> performing any file access during the loop, but only because it does not
> invoke any macros.
>
> Each return from macro currently causes the file buffer to be re-loaded.
> To make matters worse, this re-loads only the portion /after/ the
> location the macro returns to, so when the end of the loop is reached,
> the next iteration requires another buffer re-load to get back to the
> start of the loop.

Yes, that is indeed the case with my own scene: macro calls within #while loops
(hundreds to thousands of such calls.) AND, in the current state of that
2400-code-line scene, there are more comments than actual code! I never cleaned
it up :-O

Maybe my SP (sloppy programming) is another factor that is 'swamping' any
improvements in the parse time. Mea culpa.

Post a reply to this message