Get email delivery of the Cadence blog featured here
[Team Specman welcomes back Methodology R&D leader Efrat Shneydor to present a 5 part series on performance-aware e coding guidelines.]
As all Specmaniacs know, the "e" language is flexible and powerful, containing many constructs that allow users to implement virtually anything. The downside of this freedom is that sometimes developers do not make the best choices when it comes to writing efficient code. Specifically, while code might achieve the required behavior, developers and users might not know what the run time and memory performance costs are for different coding styles. In this series, I will present some guidelines for performance-aware coding. First topic: Lists.
Improving List Performance
In Specman, some of the list pseudo methods actually create new lists themselves. In small environments with small lists this is not an issue. But when there are many long lists, the effect on memory consumption can become significant in a bad way. Fortunately, such “expensive” pseudo methods can often be replaced with better performing code. The following table shows some “expensive” actions, and the better way for achieving same result.
In the next segment of this series, I’ll show you how you can save memory with base-type extensions via by following one simple rule, and how to save memory using CONST fields.
I am glad to to see you find this kind of info usefull, stay tune - more is coming...
Regarding your question - no, there is no advantage - in memory or CPU or speed - of size() of count().
Quite an useful post!
Regarding the first comparison between list.all(...).size() and list.count(), although the former creates a new list isn't it considered to be faster?