Yes. One of the ways to improve the runtime performance of the OSS API functions is to avoid using fixed size arrays for large lists of values or for large strings. Instead, you can use the LINKED or UNBOUNDED representation for large lists or strings. The use of arrays for large lists of values may result in poor performance, since the ASN.1 compiler generates a fixed inline array (when the ARRAY representation is in use) large enough to fit the maximum allowed data size specified in the ASN.1 subtype constraint. Since your application may very well only use a portion of the total allocated memory, the unused portion will contribute to wasted resources.
For this reason, the ASN.1 compiler issues a warning message if arrays are being used for the C representation of a type which requires more than 64 kilobytes of memory. To aid efficiency, the ASN.1 compiler by default represents SEQUENCE OF and SET OF types as linked lists. Similarly, BIT STRING, OCTET STRING, other string types are represented, by default, with a structure containing a length and value pointer pair (i.e. the UNBOUNDED representation). However, if you find that the compiler generates an array representation for some type, you can transform it into the linked list or length/value-pointer representation by using the local or global
OSS.LINKED or OSS.UNBOUNDED compiler directive for that type in your ASN.1 specification and recompiling.
Another way to improve runtime performance is to disable some or all of the diagnostic capabilities of the OSS encoder/decoder. This is desirable after you have completed the development and testing phase of your application. To disable the diagnostic capabilities, you can do one or more of the following:
(a) Do not set the DEBUGPDU flag before calling the encoder/decoder. This will disable time-consuming tracing activity during encoding/decoding operations.
(b) Specify the ASN.1 compiler command line option -minimize when compiling your ASN.1 syntax. This will probably lead to a smaller .c file and will result in only crucial constraint checking being done on values which are being encoded/decoded.
(c) Specify the NOCONSTRAIN flag before calling the encoder/decoder, thereby disabling runtime constraint checking while retaining the ability to later enable it if the need arises.
(d) Specify the NOTRAPPING flag before calling the encoder/decoder. This disables the trapping of memory violations and prevents the construction of an error message that details which field of the PDU was being processed when the memory violation occurred. If your application is fully tested, you have every reason to specify
The above four items will definitely improve performance. Depending on your ASN.1 specification you may also be able to improve performance by pre-allocating the encoder/decoder output buffer.
Another possible way to improve performance is to switch among the three types of encoders and decoders provided by OSS.
The samples included with some of the Knowledge Center answers are meant for your general understanding of the OSS products. Different versions of the products might produce slightly different outputs. Consult the products documentation and samples for the most up-to-date products information and code examples.
Test drive the OSS Nokalva ASN.1, LTE, and XML Tools now! Your trial includes complete software, documentation, sample programs, free 24x7 technical support and more.
Our expert personnel can help you learn ASN.1!
We offer 4-day ASN.1 courses at our headquarters or your premises.