Components or @ commands?

[Rado1]

I started to optimize my projects, and in order to reduce the size of the project tree I rewrote many components to their @ variants in expressions. For example:

Code: Select all

// read level index file
@FileAction(File: LevelIndexFile, Action: 0);
if(FileExists) @SetAppState(State: TitleAppState);

The functionality is not so obvious from the project tree, but it is more "consistent" and there's the possibility to use local variables, ifs, fors, switches, etc.

My question is: what's the performance of @ script commands - better, worse, or the same as the original components?

[Kjell]

Hi Rado1,

I started to optimize my projects, and in order to reduce the size of the project tree I rewrote many components to their @ variants in expressions.

The filesize of your zgeproj won't differ much one way or another. It's purely a aesthetic preference if you prefer tree-based components or expression-based component-calls.

My question is: what's the performance of @ script commands - better, worse, or the same as the original components?

It's identical. Besides, the component overhead will generally only account for a neglectable sliver of the entire performance footprint.

K

[Rado1]

Good to know. I rewrote a lot of code and I do not want to revert it back due to performance issues. Thank you Kjell.

BTW this reminds me older feature request of adding line numbers and better syntax error reporting for expressions discussed in this post.

[Kjell]

Hmm,

this reminds me older feature request of adding line numbers and better syntax error reporting for expressions

The SynEdit control shows line-numbers by default ( in Lazarus at least ), so no idea why this isn't there in the first place.



*Screenshot of Delphi SynEdit control ( with custom popup menu ).

K

[VilleK]

Hi, download beta again for line numbers. It was just a flag that needed to be set.

[Rado1]

download beta again for line numbers

Thank you Ville, I like line numbers. The only remaining thing is to extend expression syntax error messages to show line numbers. And maybe one additional improvement: allow to change font size in expression editor (e.g. by context menu or in Settings).

[VilleK]

I've now added line/column info to scripting parser errors so it will say "invalid primary (line:x, col:y)" and similar. Download the beta again. It won't affect all messages though because some error messages are from the code generation phase and by that time the line/col information is no longer available. Let me know if you get many errors without line numbers and I can try to find a way to improve it.

[Rado1]

I like the feature, thanks! Many invalid StatementExpr errors can be identified very easily.

Code: Select all

1 int var;
2 xx;
3 var = x;

The following errors do not show line numbers:
- Unsupported operator, line 2
- Invalid address expression, line 3