Hi,
currently I developing a lot of new Atoms for ED. At the moment I don't have performance problems, but I want the keep the code fast. So I have two questions:
How much faster is Att(1,c) then Att([attributeName],c)? Do you always start a search or something or do you replace the name with the number in the background?
As from how much calls for an attribute like xSize(c) it is recommended to use a local var? (especially important for 2D/3DDraw)
Thanks
Performance Questions
Re: Performance Questions
Unfortunately the answer to your question is no jut a simple yes or no.
att(1, c) is faster than att([attName], c). The former is found directly by a index. The latter compares all attributes by name until the correct one if found (note the for normal ED atoms this is faster than a hash map). Though, in the many test we've done you don't see any significance difference in performance.
If you just use the attribute name (without att([])) within the eventcode of an atom it is automatically compiled to att(#, c).
The problem with att(#) is readability and maintainability of code. The problem with att([attName]) is that you can make a typing error in the attribute name. As a solution we normally create attribute get and set functions. Inside the function the attribute number is called (the fastest way to call an attribute). The advantage of this approach besides that the code is readable is that you have code completion within your code. The eliminates the risk of typing errors and the functions. This functionality becomes available (with a GUI) with upcoming ED9 release (later this month) as a developer tools package which will become available for download on our website.
xSize(c) is a direct atom property and has nothing to do with attributes.
To answer you question if you use attribute calls more than once within a function it is in general faster to use a local variable. But if you use attributes within the 2D and 3D code and the attribute just contains a value then you can also use the attribute name as described above. Also within function we generally use local variables to store the function parameters (p(1), etc). This to make the code more readable.
Good luck with your development,
Jeroen Bijsterbosch
att(1, c) is faster than att([attName], c). The former is found directly by a index. The latter compares all attributes by name until the correct one if found (note the for normal ED atoms this is faster than a hash map). Though, in the many test we've done you don't see any significance difference in performance.
If you just use the attribute name (without att([])) within the eventcode of an atom it is automatically compiled to att(#, c).
The problem with att(#) is readability and maintainability of code. The problem with att([attName]) is that you can make a typing error in the attribute name. As a solution we normally create attribute get and set functions. Inside the function the attribute number is called (the fastest way to call an attribute). The advantage of this approach besides that the code is readable is that you have code completion within your code. The eliminates the risk of typing errors and the functions. This functionality becomes available (with a GUI) with upcoming ED9 release (later this month) as a developer tools package which will become available for download on our website.
xSize(c) is a direct atom property and has nothing to do with attributes.
To answer you question if you use attribute calls more than once within a function it is in general faster to use a local variable. But if you use attributes within the 2D and 3D code and the attribute just contains a value then you can also use the attribute name as described above. Also within function we generally use local variables to store the function parameters (p(1), etc). This to make the code more readable.
Good luck with your development,
Jeroen Bijsterbosch
Re: Performance Questions
Hi Jeroen,
your answer helped me a lot! Thanks.
P.S.: Good to know that ED9 comes soon
your answer helped me a lot! Thanks.
P.S.: Good to know that ED9 comes soon