Users evaluating our ASN1C SDK frequently find they don’t get the encoding or decoding performance they hoped for. The libraries we provide for evaluation have less-than-optimal performance for two reasons: they are not optimized and they include license checking overhead. Customers who need to evaluate performance characteristics can request access to optimized libraries, but without doing that, what are some reasonable expectations?
We recently did some performance analysis to help a potential customer evaluate performance. The analysis was for decoding of LTE RRC messages using C++. We used ASN1C 7.4, the statically-linked ASN1C libraries, and Visual Studio 2019. Due to possible variations in specifications, data sets, and hardware, I don’t report absolute measurements here, but rather relative measurements of elapsed wall clock time.
|Non-optimized, limited (license-checked) library (baseline)
|Non-optimized (debug), unlimited (license-check free) library
|Optimized, limited (license-checked) library
|Optimized, unlimited (license-check free) library
|Optimized, unlimited (license-check free) library, with code generation changes (see below for details)
||<2% (8.5% of the time for the same library without the code generation changes)
In this test, we found that the optimized, unlimited library used roughly 20% of the time used by the non-optimized, limited library provided with the evaluation SDK (that’s an 80% reduction in elapsed time).
In this particular case, we did some further experimentation to see what could be done with the generated code to get even better performance using the optimized, unlimited library. We found that by removing some generated diagnostics-related code and using dynamic arrays instead of linked lists, we achieved a tremendous further performance boost. (We generated code using the -dynamicArray option and compiled it with _COMPACT defined). By doing this, we found the time used was less than 2% of the baseline, and only 8.5% of the time used by the optimized, unlimited library.
We are pleased to announce a new major release of ASN1C for 2020, version 7.4.
The main new feature in this release is the capability to generate Python encoders and decoders. Currently supported is generation of code for the BER/DER and JSON (JER) encoding rules. The BER support includes options to generate forward encoders using indefinite lengths and also includes support for parsing and formatting 3GPP TS 32.297 headers as used in standard 3GPP CDR formats.
The new capability provides for generation of 100% Python code, not wrappers around platform-specific DLL’s or shared object files.
We plan to add support for PER, OER, and XER later this year.
In addition to Python, other features in the new release include:
- Support for 5G ASN.1-based protocols as well as 5G NAS (3GPP TS 24.501)
- Support for Visual Studio 2019 in the Windows versions
- The capability to use ASN1C project files created with the GUI from the command-line
Further information can be found in the documentation on the product support page.
We are proud to announce the release of new major versions of our ASN1VE and ASN2TXT products for 2020.
ASN1VE (ASN.1 Viewer / Editor) is a graphical user interface (GUI) tool for analyzing and editing ASN.1 encoded data. In the new 3.0 release, we have added the following capabilities:
- Added verification and encoding support for canonical encoding rules including DER, CER, and COER. The new capability checks for canonical rule violations within the encoded data. New messages can be created in these formats and existing messages transformed to ensure canonical form.
- The capability to import JSON or XML messages into Octet Encoding Rules (OER) format has been added.
- The capability to copy and paste tree nodes in element view has been added.
- Improved performance in loading and searching for data in large TAP3 and other CDR files.
- Changed the Windows installation procedure to first deinstall an existing version before trying to install a newer version.
ASN2TXT (ASN.1 to text translator) is a command-line tool for translating ASN.1 encoded data to and from various textual formats (XML, JSON, CSV). The main new capability added in the 3.0 release is a Python wrapper that makes it possible to use the DLL in Python applications.
Other new features for the two products are documented in the Release Notes and Change Log. See the Product Support Page at obj-sys.com/support.php
We’ve updated the Python wrapper in our V2X API packages to support Python 3 (in addition to supporting Python 2.7). Also, all platforms, not just 64-bit ones, now include the Python wrapper.
About Objective System’s V2X API
The V2X API is available for C++, Java, and C#. It supports encoding/decoding V2X messages defined by SAE J2735 and ETSI standards.
The Python wrapper enables easy conversion between binary and text encodings by providing a simple Python interface on top of the C++ API.
For more, go here.
This is an update to the original blog post on this topic done on June 28, 2011 at http://www.obj-sys.com/blog/?p=355. At the time, we did not have support in ASN1VE to process 3GPP TS 32.297 CDR headers, which is what the Huawei IMS CDR’s mentioned in the post contained. Although it is still possible to skip these headers, this is not reliable as the headers may be variable length. The updated procedure to view these CDR files with a newer version of ASN1VE is as follows:
- Open the CDR file. The “Assign All Items Wizard” popup window will appear:
Select the “cdr” option (not “ber”) and click Next.
The second wizard popup will appear:
On this popup, check the “3GPP TS 32.297 Headers” radio button and click Next.
The normal procedure for assigning an ASN.1 schema file can then be followed from that point forward. The result will be the display of the CDR file with the headers fully decoded.
An example of this can be found in the sample/ts32297 directory within an ASN1VE installation.