ASN.1 Tools for C — Runtime Choices

Throughout the years, OSS Nokalva's customers have had many different requirements for code size, encoding/decoding speed and diagnostic capabilities on various mainstream and embedded platforms. To satisfy our customers' various needs, OSS Nokalva offers our ASN.1 Tools for C runtime libraries in three flavors.

All three flavors of the runtime libraries perform the same function and have an identical API consisting of functions for encoding/decoding ASN.1 messages, functions for copying, comparing, printing, and freeing unencoded/decoded messages, a simple, yet flexible memory management interface, and many other useful functions.

You can change from using one flavor of the ASN.1/C runtime to using another with no impact to your application code. See the "ASN.1/C Runtime API" manual for detailed instructions on how to switch between the various runtime flavors.


The Space-Optimized Encoder/Decoder (SOED) was so named because of its emphasis on minimizing memory usage (i.e., small code size), especially when the ASN.1 specification is large or complex. SOED is a popular choice for use during development. It offers a wealth of tracing, error trapping, diagnostic and recovery capabilities, our most flexible memory manager, and the ability to work interactively with an ASN.1 specification (which is useful, for example, when you need to read information about the constraints of a particular ASN.1 type at runtime).


The time-optimized encoder/decoder (TOED) is a popular choice for deployment because of its emphasis on minimizing CPU utilization. We purposely minimized the tracing capability and used a code-driven rather than table-driven design to achieve lightning speed.

LED (packaged separately)

The lean encoder/decoder (LED) is optimized to offer a smaller code size than the SOED, yet fast encode/decode performance. It purposely does not possess a wealth of tracing and diagnostic capabilities. It is often the best choice for working with large ASN.1 specifications, particularly when your software runs on systems with significant memory constraints.

For details about each of the ASN.1/C runtimes, please consult the "ASN.1/C Runtime API" manual.

Which ASN.1/C Runtime is Right for Me?

Use the table below to choose the ASN.1/C runtime that best suits your needs, based on its performance (expressed as both code size and the speed of encoding) and diagnostic capabilities.




Encoding/Decoding Speed




Code Size(1)




Diagnostic Capabilities




Ideal for Use During

Development and Deployment



Best Suited for

  • Diagnosis during development
  • Applications used for testing
  • Applications that need to encode/decode messages without prior knowledge of ASN.1 types and constraints
  • Large/complex ASN.1 specs
  • Memory limitations
  • Small ASN.1 specs
  • Very high speed requirements
  • Large ASN.1 specs
  • High speed requirements
  • Memory limitations

(1) The size of the code generated by the ASN.1 compiler is highly dependent on the particular ASN.1 specification used.

(2) If your ASN.1 specification is short and simple, the size of the executable for use with TOED could be comparable with the size of the executable for use with LED.

Runtime Performance Comparison

The following charts depict runtime performance results based on several standard ASN.1 specifications to help you get a feel for the comparative performance (code size and time spent during encoding/decoding) of each of the ASN.1/C runtime flavors.

If you can't find your ASN.1 specification below, you can approximate the relative performance of SOED/TOED/LED based on the size of your specification and/or the encoding rule used.

Encoding/Decoding Speed (relative)

Executable Size (relative)

This comparison is presented for illustration purposes only. If you are interested in a complete performance comparison, please contact us.

Performance Comparison Methodology

The encoding/decoding times and executable sizes for all ASN.1 specifications are presented relative to the smallest ones (1x). The encoding/decoding time was averaged for several different messages and normalized based on the size of the messages. For both charts, an exponential scale was used. Smaller bars reflect better performance.

The same generic encoding/decoding application was used for all measurements. The size of the application object code was compared, which was obtained from C-compiling and linking the sources and the control table (if applicable) generated by the ASN.1 compiler, as well as the application code and the corresponding runtime libraries.