ASN1C New Space-Optimization Feature

How much space can you save?

To get an idea of the potential savings, we compared the overall size of a simple executable, with and without the space-optimization feature, as well as the size of the object files related to encoding, decoding and memory freeing, with and without the feature. This gives you an idea of the savings in the context of an executable (where the linked libraries impact the overall size), as well as the savings for just the parts actually being swapped (i.e. the table data versus the functional code).

For this comparison, we generated code for the 3GPP LTE NR RRC specification.

A few quick notes:

• Binaries were statically linked with our unlimited (i.e. no license checking), optimized, compact runtime libraries.
• Code was compiled with Visual Studio 2022, using /O1.

Overall executable size comparision:

Object file size comparision for table source (SO) vs. functional source (not SO), for encoding, decoding, and free:

Switching between space-optimized and non-space-optimized

For new work, it's easy to switch between using and not using the space-optimization feature. For existing work, you might have to change some command line options, and that might require changes to your code. Here are the things to know:

• Either way, the same types are generated.
• Either way, the same PER encode, decode, and free functions are generated, except that in the space-optimized case, they are actually macros.
• The space-optimization option requires using certain command line arguments. If you aren't already using those arguments and you switch to space-optimized, you may have to adjust some of your code to account for differences due to those arguments. For example, -dynamic is required, and that changes some non-pointer types into pointer types that must point to dynamically allocated memory.

Limitations

The main limitations to be aware of are:

• Only C and unaligned PER are supported.
• Constraints are not enforced, outside of limitations imposed by the schema-informed nature of PER. For example, INTEGER(0..6) is encoded in 4 bits. The value 7 does not satisfy the constraint, but it will be accepted because it can be encoded in 4 bits.
• Table constraints are ignored.
• Data for unknown extension additions will be discarded by decoders and cannot be encoded by encoders.
• There are various limitations on the schema (e.g. size constraint bounds). These are documented in the manual, but the compiler should tell you if your schema is not supported.

Any Disadvantages?

Besides the limitations above, using space-optimized code is a space-time tradeoff. Your code will use much less space, but it will also run slower. Of course, even if your application's execution time is important, how much this will impact your application overall depends on how much of your overall processing consists of encoding/decoding ASN.1 data. To help give you an idea of the potential impact, we took some measurements. Our technique used the Windows Profiling API (QueryPerformanceCounter) to measure each operation individually, and then we took the average over 10,000 invocations. The time measurements are in microseconds. We linked and built our test application as described above, for analyzing the binary code size.

For a 2348-byte UE-NR-Capability message, we had the following results:

For a 111-byte SIB4 message, we had the following results:

For More Information

For more information, refer to the manual.