Performance-Aware e Coding Guidelines – Part 2

Building on Part 1 where I talked about the “do’s and don’ts” of List performance, in this segment on performance-aware coding I’ll show you some memory saving tips.  We base this segment on base types (geeky pun intended) …

Base types extensions
Creating base classes with functionality that is common to many environments is a good practice.  In this way you “develop once” (and even more importantly – maintain only one copy), and benefit from reuse in many subsequent environments.  However, if you take this too far by adding fields to the e base types any_struct or any_unit – you can cause yourself some trouble.  Here is why: recall that any member you add to these base types will appear in each and every struct.  Consequently, instead of extending all the base types, we recommend extending only the OVM e base types.  Thus, when you extend specific base types (like ovm_agent, ovm_monitor, etc) – only the relevant units will contain the added functionality, saving memory in the process.

Const fields
When instantiating a struct that has several sub-types, Specman allocates memory for all optional fields.  For example, whenever instantiating the packet header struct defined below, Specman will allocate memory for all fields – those defined under “when CTRL” and those defined under “when DATA”.

struct packet_header_s {

    kind : packet_kind_t;

    when CTRL packet_header_s {

      /// many control fields …

    };

    when DATA packet_header_s {

      /// many data fields …

    };

};

However, this header kind is not expected to change during the run, so it can be defined as const. When const is used, Specman will allocate only the fields under the corresponding sub-type, potentially saving a lot of memory in the process.  Here is an example:

struct packet_header_s {

    const kind : packet_kind_t;

    when CTRL packet_header_s {

      /// many control fields …

    };

    when DATA packet_header_s {

      /// many data fields …

    };

};

struct packet_s {

    kind : packet_kind_t;

    header : packet_header_s;

    when DATA packet_s {

        keep type header is a DATA packet_header_s

    };

    when CTRL packet_s {

          keep type header is a STS packet_header_s

    };

};

Naturally, if you are in the early stages of development it would be best to adopt these techniques as part of your regular coding style.  But even if you are in maintenance or simple test writing stages, I believe it will be well worth the extra time to re-work and improve your environment.  In either case, you might want to run Specman CPU and MEM profiler, before and after modifying the code – I believe you will like what you see.

Next segment in the series:
Some performance tips for speeding up everyone’s favorite e / Specman capability: Generation!
 
Happy coding!

Efrat Shneydor
Methodology R&D

Reference link:  Part 1 on improving the performance of Lists