In order to determine the practical impact of the different code generation alternatives on execution time, we measured the execution time for a number of benchmarks written in ASN.1. Measurements were done on a Sun Sparc 10, Model 40, using gcc version 2.6.0, static linking and optimization level 2 (O2). The presentation conversion code was generated by the ASN.1 compiler Mavros (Huitema, 1991).
We used one benchmark for each of the four type constructors available in the interface definition language ASN.1 (Steedman, 1990). The Sequence type corresponds to a structure type in C. The Set type is a special case of a structure where structure fields can be reordered before they are sent out on the net. The Choice type corresponds to a C union type. The Sequence Of type is equivalent to an array in C. In all experiments, the type definition contained ten integer values.
Table 2 gives the throughput measured in these experiments for interpreted and procedure-driven presentation conversion code. For each experiment, we report three values: the throughput of interpreted code, the throughput of procedure-driven code and the factor by which interpreted code is slower than procedure-driven code. The latter serves to eliminate system-dependencies inherent in the absolute values.
From these numbers we see that the speed difference between interpreted and procedure-driven presentation conversion code is significant. Compiled code is consistently faster than interpreted code by a factor of 1.6 to 5.7. Some of the numbers measured for interpreted code are not sufficient to saturate an Ethernet (10 Mbit/s), and none of the alternatives can saturate network connections with higher throughputs such as FDDI (100 Mbit/s) or the ATM configuration commonly used with workstations (155 Mbit/s). Another observation is that unmarshalling is consistently slower than marshalling. This is due to the requirement for error-checking in unmarshalling code.
We conclude that from a performance point of view the use of procedure-driven presentation conversion code is preferable to the use of interpreted code. The choice of the implementation technique for presentation conversion code can decide whether the installation of expensive high-speed network was worthwhile for speeding up a particular implementation. Installing an ATM network is of little use if the presentation conversion code of an application executes at Ethernet throughput.
Table 2: Throughput of interpreted and procedure-driven presentation
conversion code
However, making presentation conversion code faster has the drawback of increasing its code size. Table 3 shows the difference in code size between interpreted and procedure-driven presentation conversion code when generating presentation conversion code for four different applications whose interfaces are specified in ASN.1. The numbers include both the marshalling and the unmarshalling routines. The numbers in the "interpreter" column give the object size of the interpreter commands generated. The interpreter itself takes up an additional 8 KByte. X.400 is the e-mail protocol defined in the ISO-OSI protocol stack, Z39.50 is an information retrieval protocol, FTAM is the ISO-OSI protocol for file transfer, access and management, and X.500 is the ISO-OSI protocol defined for access to a directory service. The same configuration and compilers as in the throughput measurements were used.
As can be seen from the numbers in Table 3, the size of procedure-driven presentation conversion code is significantly larger than the size of interpreted code. This becomes even clearer when comparing the aggregate code sizes. Aggregate code size is important, since network applications are usually run in the background. If these network applications take up too much memory space, it may impossible to run interactive applications such as a word processor.
Table 3: Size of interpreted and procedure-driven presentation conversion code