Cadence.com will be under maintenance from Friday, Oct. 3rd at 6pm (PST) thru Sunday, Oct 5th at 11pm (PST).
Cadence.com login, registration, community posting and commenting functionalities will be disabled.
Home > Community > Blogs > Functional Verification > performance aware e coding guidlines part 1
 
Login with a Cadence account.
Not a member yet?
Create a permanent login account to make interactions with Cadence more convenient.

Register | Membership benefits
Get email delivery of the Functional Verification blog (individual posts).
 

Email

* Required Fields

Recipients email * (separate multiple addresses with commas)

Your name *

Your email *

Message *

Contact Us

* Required Fields
First Name *

Last Name *

Email *

Company / Institution *

Comments: *

Performance-Aware e Coding Guidelines - Part 1

Comments(2)Filed under: Functional Verification, Incisive Enterprise Simulator (IES), e, Specman, IEEE 1647, IntelliGen, IES-XL, tech tips, specman elite, performance

[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.

 

e_list_performance_do_and_dont

 

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.

 

Happy coding!

Efrat Shneydor
Methodology R&D

Comments(2)

By Gaurav Jalan on April 2, 2009
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?

By Efrat Shneydor on April 5, 2009
hi,
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().

Leave a Comment


Name
E-mail (will not be published)
Comment
 I have read and agree to the Terms of use and Community Guidelines.
Community Guidelines
The Cadence Design Communities support Cadence users and technologists interacting to exchange ideas, news, technical information, and best practices to solve problems and get the most from Cadence technology. The community is open to everyone, and to provide the most value, we require participants to follow our Community Guidelines that facilitate a quality exchange of ideas and information. By accessing, contributing, using or downloading any materials from the site, you agree to be bound by the full Community Guidelines.