davidk@dsinet (David Karr) (04/25/91)
We have recently gone through the effort of getting the ISODE up to see if we could use it to implement an intersystem/process messaging system for a product we are working on. We very much want to go OSI, but after running benchmarks comparing a relatively simple data structure transfer using both ASN.1 and XDR, we find the ASN.1 process running 100(!) times slower than the XDR process. This is unacceptable. Our eventual throughput with ASN.1 was barely over 2k bytes per second. We noticed that ASN.1 is doing tons of mallocs/frees to get it's job done, where XDR (HP-UX implementation) is executing very few (relatively) system calls to get its job done. Is it possible we are missing something in our configuration that is making the ASN.1 process so slow? I don't know if it matters, but we are using version 6.0 of the ISODE. I believe it is up to about 6.7f. -- Digital Systems International, Inc. David Karr 7730 177th Pl NE dsinet!davidk Redmond, WA 98073-0903 (206) 881-7544 ext. 547
djw@bbn.com (David Waitzman) (05/01/91)
davidk@dsinet (David Karr) writes: }We noticed that ASN.1 is doing tons of }mallocs/frees to get it's job done, where XDR (HP-UX implementation) is }executing very few (relatively) system calls to get its job done. Is it }possible we are missing something in our configuration that is making the }ASN.1 process so slow? By its very nature, ASN.1 using BER encoding will always be slower than XDR. ISODE's implementation is designed for quick experimentation and prototyping, not for speed--- so, you observed how it is SUPPOSED to behave. You could hand-code your ASN.1/BER encoding/decoding routines to get much more speed. There have been some papers comparing ASN.1/BER, XDR, and Apollo-NCS in various places. Craig Partridge was an author of one of them (I don't remember where, trying asking Craig at craig@sics.se). BER is the only current standard way of encoding ASN.1. Some people are working on faster methods. I believe that an issue of CCR (the magazine for ACM Sigcomm) had an article about this last year. -david