The following paper was originally published in the
`Proceedings of the 4th USENIX Conference on Object-Oriented Technologies and Systems (COOTS)
`Santa Fe, New Mexico, April 27-30, 1998
`
`The Design and Performance of MedJava
`
`Prashant Jain, Seth Widoff, and Douglas C. Schmidt
`Washington University
`
`For more information about USENIX Association contact:
`1. Phone:
`510 528-8649
`2. FAX:
`510 548-5738
`3. Email:
`office@usenix.org
`4. WWW URL: http://www.usenix.org/
`
`Apple/Twitter
`Ex. 1017
`IPR2 of U.S. Pat. No. 7,765,482
`
`

`

`The Design and Performance of MedJava
`A Distributed Electronic Medical Imaging System
`
`Developed with Java Applets and Web Tools
`
`Prashant Jain, Seth Widoff, and Douglas C. Schmidt
`fpjain,sbw1,schmidtg@cs.wustl.edu
`Department of Computer Science
`Washington University
`St. Louis, MO 63130, (314) 935-4215
`
`This paper appeared in the th USENIX Conference on
`Object-Oriented Technologies and Systems (COOTS), Sante
`Fe, New Mexico, April 1998.
`
`Abstract
`
`The Java programming language has gained substantial popu-
`larity in the past two years. Java’s networking features, along
`with the growing number of Web browsers that execute Java
`applets, facilitate Internet programming. Despite the popu-
`larity of Java, however, there are many concerns about its ef-
`ficiency.
`In particular, networking and computation perfor-
`mance are key concerns when considering the use of Java to
`develop performance-sensitive distributed applications.
`This paper makes three contributions to the study of Java for
`performance-sensitive distributed applications. First, we de-
`scribe an architecture using Java and the Web to develop Med-
`Java, which is a distributed electronic medical imaging sys-
`tem with stringent networking and computation requirements.
`Second, we present benchmarks of MedJava image processing
`and compare the results to the performance of xv, which is an
`equivalent image processing application written in C. Finally,
`we present performance benchmarks using Java as a transport
`interface to exchange large medical images over high-speed
`ATM networks.
`For computationally intensive algorithms, such as image
`filters, hand-optimized Java code, coupled with use of a JIT
`compiler, can sometimes compensate for the lack of compile-
`time optimization and yield performance commensurate with
`identical compiled C code. With rigorous compile-time opti-
`mizations employed, C compilers still tend to generate more
`efficient code. However, with the advent of highly optimiz-
`ing Java compilers, it should be feasible to use Java for the
`
`

`

`DDXX
`IIMMAAGGEE
`SSTTOORREE
`
`AATTMM
`LLAANN
`
`AATTMM
`MMAANN
`
`DDIIAAGGNNOOSSTTIICC
`SSTTAATTIIOONNSS
`
`AATTMM
`LLAANN
`
`CCLLUUSSTTEERR
`IIMMAAGGEE
`SSTTOORREE
`
`MMOODDAALLIITTIIEESS
`((CCTT,, MMRR,, CCRR))
`
` CCEENNTTRRAALL
`IIMMAAGGEE
`SSTTOORREE
`
`Figure 1: Topology of a Distributed EMIS
`
`transfer of images efficiently, reliably, and economically.
`Image processing is a set of computational techniques for
`enhancing and analyzing images.
`Image processing tech-
`niques apply algorithms, called image filters, to manipulate
`images. For example, radiologists may need to sharpen an
`image to properly diagnose a tumor. Similarly, to identify a
`kidney stone, a radiologists may need to zoom into an image
`while maintaining high resolution. Thus, an EMIS must pro-
`vide powerful image processing capabilities, as well as effi-
`cient distributed image retrieval and storage mechanisms.
`This paper describes the design and performance of Med-
`Java, a distributed EMIS developed using the Java environ-
`ment and the Web. The paper examines the feasibility of us-
`ing Java to develop large-scale distributed medical imaging ap-
`plications with demanding performance requirements for net-
`working speed and image processing speed.
`To evaluate Java’s image processing performance, we con-
`ducted extensive benchmarking of MedJava and compared the
`results to the performance of xv, an equivalent image process-
`ing application written in C. To evaluate the performance of
`Java as a transport interface for exchanging large images over
`high-speed networks, we performed a series of network bench-
`marking tests over at 155 Mbps ATM switch and compared the
`results to the performance of C/C++ as a transport interface.
`Our empirical measurements reveal that an imaging system
`implemented in C/C++ always out-performs an imaging sys-
`tem implemented using interpreted Java by 30 to 100 times.
`
`2
`
`However, the performance of Java code using a “just-in-time”
`(JIT) compiler is 1.5 to 5 times slower than the performance
`of compiled C/C++ code. Likewise, using Java as the transport
`interface performs 2% to 50% slower than using C/C++ as the
`transport interface. However, for sender buffer size close to
`the network MTU size, the performance of using Java as the
`transport interface was only 9% slower than the performance
`of using C/C++ as the transport interface. Therefore, we con-
`clude that it is becoming feasible to use Java to develop large-
`scale distributed EMISs. Java is particularly relevant for wide-
`area environments, such as teleradiology, where conventional
`EMIS capabilities are too costly or unwieldy with existing de-
`velopment tools.
`The remainder of this paper is organized as follows: Sec-
`tion 2 describes the object-oriented (OO) design and features
`of MedJava; Section 3 compares the performance of MedJava
`with an an equivalent image processing application written in
`C and compares the performance of a Java transport interface
`with the performance of a C/C++ transport interface; Section 4
`describes related work; and Section 5 presents concluding re-
`marks.
`
`2 Design of the MedJava Framework
`
`2.1 Problem: Resolving Distributed EMIS De-
`velopment Forces
`
`A distributed electronic medical imaging system (EMIS) must
`meet the following requirements:
` Usable: An EMIS must be usable to make it as convenient
`to practice radiology as conventional film-based technology.
` Efficient: An EMIS must be efficient to process and de-
`liver medical images rapidly to radiologists.
` Scalable: An EMIS must be scalable to support the grow-
`ing demands of large-scale integrated health care delivery sys-
`tems [2].
` Flexible: An EMIS must be flexible to transfer different
`types of images and to dynamically reconfigure image pro-
`cessing features to cope with changing requirements.
` Reliable: An EMIS must be reliable to ensure that medi-
`cal images are delivered correctly and are available when re-
`quested by users.
` Secure: An EMIS must be secure to ensure that confiden-
`tial patient information is not compromised.
` Cost-effective: An EMIS must be cost-effective to mini-
`mize the overhead of accessing patient data across networks.
`
`Developing a distributed EMIS that meets all of these re-
`quirements is challenging, particularly since certain features
`
`

`

`conflict with other features. For example, it is hard to develop
`an EMIS that is efficient, scalable, and cost-effective. This is
`because efficiency often requires high-performance computers
`and high-speed networks, thereby raising costs as the number
`of system users increases.
`
`2.2 Solution: Java and the Web
`
`Over the past two years, the Java programming language has
`sparked considerable interest among software developers. Its
`popularity stems from its flexibility, portability, and relative
`simplicity compared with other object-oriented programming
`languages [5].
`The strong interest in the Java language has coincided with
`the ubiquity of inexpensive Web browsers. This has brought
`the Web technology to the desktop of many computer users,
`including radiologists and physicians.
`A feature supported by Java that is particularly relevant to
`distributed EMISs is the applet. An applet is a Java class that
`can be downloaded from a Web server and run in a context
`application such as a Web browser or an applet viewer. The
`ability to download Java classes across a network can simplify
`the development and configuration of efficient and reliable dis-
`tributed applications [6].
`Once downloaded from a Web server, applets run as appli-
`cations within the local machine’s Java run-time environment,
`which is typically a Web browser. In theory, therefore, applets
`can be very efficient since they harness the power of the local
`machine on which they run, rather than requiring high latency
`RPC calls to remote servers [7].
`The MedJava distributed EMIS was developed as a Java ap-
`plet. Therefore, it exploits the functionality of front-ends of-
`fered by Web browsers. An increasing number of browsers
`(such as Internet Explorer and Netscape Navigator and Com-
`municator) are Java-enabled and provide a run-time environ-
`ment for Java applets. A Java-enabled browser provides a Java
`Virtual Machine (JVM), which is used to execute Java applets.
`MedJava leverages the convenience of Java to manipulate im-
`ages and provides image processing capabilities to radiologists
`and physicians connected via the Web.
`In our experience, developing a distributed EMIS in Java is
`relatively cost effective since Java is fairly simple to learn and
`use. In addition, Java provides standard packages that support
`GUI development, networking, and image processing. For
`example, the package java.awt.image contains reusable
`classes for managing and manipulating image data, including
`color models, cropping, color filtering, setting pixel values,
`and grabbing bitmaps [8].
`Since Java is written to a virtual machine, an EMIS devel-
`oper need only compile the Java source code to Java bytecode.
`The EMIS applet will execute on any platform that has a Java
`
`Virtual Machine implementation. Many Java bytecode com-
`pilers and interpreters are available on a variety of platforms.
`In principle, therefore, switching to new platforms or upgraded
`hardware on the same platform should not require changes to
`the software or even recompilation of the Java source. Conse-
`quently, an EMIS can be constructed on a network of hetero-
`geneous machines and platforms with a single set of Java class
`files.
`
`2.3 Caveat: Meeting EMIS Performance Re-
`quirements
`
`Despite the software engineering benefits of developing a dis-
`tributed EMIS in Java, there are serious concerns with its per-
`formance relative to languages like C and C++. Performance
`is a key requirement in a distributed EMIS since timely diag-
`nosis of patient exams by radiologists can be life-critical. For
`instance, in an emergency room (ER), patient exams and med-
`ical images must be delivered rapidly to radiologists and ER
`physicians. In addition, an EMIS must allow radiologists to
`process and analyze medical images efficiently to make ap-
`propriate diagnoses.
`Meeting the performance demands of a large-scale dis-
`tributed EMIS requires the following support from the JVM.
`First, its image processing must be precise and efficient. Sec-
`ond, its networking mechanisms must download and upload
`large medical images rapidly. Assuming that efficient image
`processing algorithms are used, the performance of a Java ap-
`plet depends largely on the efficiency of the hardware and the
`JVM implementation on which the applet is run.
`The need for efficiency motivates the development of high-
`speed JIT compilers that translate Java bytecode into native
`code for the local machine the browser runs on. JIT compil-
`ers are “just-in-time” since they compile Java bytecode into
`native code on a per-method basis immediately before calling
`the methods. Several browsers, such as Netscape and Internet
`Explorer, provide JIT compilers as part of their JVM.
`Although Java JIT compilers avoid the penalty of interpreta-
`tion, previous studies [9] show that the cost of compilation can
`significantly interrupt the flow of execution. This performance
`degradation can cause Java code to run significantly slower
`than compiled C/C++ code. Section 3 quantifies the overhead
`of Java and C/C++ empirically.
`
`2.4 Key Features of MedJava
`
`MedJava has been developed as a Java applet. Therefore, it
`can run on any Java-enabled browser that supports the standard
`AWT windowing toolkit. MedJava allows users to download
`medical images across the network. Once an image has been
`downloaded, it can be processed by applying one or more im-
`age filters, which are based on algorithms in the C source code
`
`3
`
`

`

`from xv. For example, a medical image can be sharpened by
`applying the Sharpen Filter. Sharpening a medical image en-
`hances the details of the image, which is useful for radiologists
`who diagnose internal ailments.
`Although MedJava is targeted for distributed EMIS require-
`ments, it is a general-purpose imaging tool that can process
`both medical and non-medical images. Therefore, in addition
`to providing medical filters like sharpening or unsharp mask-
`ing, MedJava provides other non-medical image processing
`filters such as an Emboss filter, Oil Paint filter, and Edge De-
`tect filter. These filters are useful for processing non-medical
`images. For example, edge detection serves as an important
`initial step in many computer vision processes because edges
`contain the bulk of the information within an image [10]. Once
`the edges of an image are detected, additional operations such
`as pseudo-coloring can be applied to the image.
`Image filters can be dynamically configured and re-
`configured into MedJava via the Service Configurator pattern
`[6]. This makes it convenient to enhance filter implementation
`or install new filters without restarting the MedJava applet. For
`example, a radiologist may find a sharpen filter that uses the
`unsharp mask algorithm to be more efficient than a sharpen
`filter that simply applies a convolution matrix to all the pixels.
`Doing this substitution in MedJava is straightforward and can
`be done without reloading the entire applet.
`Once an image has been processed by applying the filter(s),
`it can be uploaded to the server where the applet was down-
`loaded. HTTP server implementations, such as JAWS [11, 12]
`and Jigsaw, support file uploading and can be used by MedJava
`to upload images. In addition, the MedJava applet provides a
`hierarchical browser that allows users to traverse directories
`of images on remote servers. This makes it straightforward to
`find and select images across the network, making MedJava
`quite usable, as well as easy to learn.
`To facilitate performance measurements, the MedJava ap-
`plet can be configured to run in benchmark mode. When
`the applet runs in benchmark mode, it computes the time (in
`milliseconds) required to apply filters on downloaded images.
`The timer starts at the beginning of each image processing al-
`gorithm and stops immediately after the algorithm terminates.
`
`2.5 The OO Design of MedJava
`
`Figure 2 shows the architecture of the MedJava framework de-
`veloped at Washington University to meet distributed EMIS
`requirements. The two primary components in the architecture
`include the MedJava client applet and JAWS, which is a high-
`performance HTTP server also developed at Washington Uni-
`versity [12, 11]. The MedJava applet was implemented with
`components from Java ACE [13], the Blob Streaming frame-
`work [14], and standard Java packages such as java.awt
`
`MMeeddJJaavvaa
`
`GGUUII
`
`JJAAWWSS
`
`UURRLL
`LLooccaattoorr
`
`IImmaaggee
`PPrroocceessssoorr
`
`FFiilltteerr
`RReeppoossiittoorryy
`
`IImmaaggee
`RReessppoossiittoorryy
`
`IImmaaggee
`DDoowwnnLLooaaddeerr
`
`IImmaaggee
`UUppLLooaaddeerr
`
`FFiilltteerr
`CCoonnffiigguurraattoorr
`
`BBlloobb
`SSttrreeaammiinngg
`
`JJaavvaa AACCEE
`
`BBlloobb
`SSttrreeaammiinngg
`
`CCoommmmuunniiccaattiioonn PPrroottooccoollss
`ee..gg..,, HHTTTTPP,, DDIICCOOMM,, HHLL77
`
`Figure 2: MedJava Framework
`
`and java.awt.image. Each of these components is out-
`lined below.
`
`2.5.1 MedJava Applet
`
`The MedJava client applet contains the following components
`shown in Figure 2:
`
`Graphical User Interface: which provides a front-end to
`the image processing tool. Figure 3 illustrates the graphical
`user interface (GUI) used to display a podiatry image. The
`
`Figure 3: Processing a Medical Image in MedJava
`
`MedJava GUI allows users to download images, apply image
`processing filters on them, and upload the images to a server.
`
`4
`
`

`

`URL Locator: which locates a URL that can reference an
`image or a directory. If the URL points to a directory, the con-
`tents of the directory are retrieved so users can browse them
`to obtain a list of images and subdirectories in that directory.
`The URL Locator is used by the Image Downloader and Image
`Uploader to download and upload images, respectively.
`
`Image Downloader: which downloads an image located by
`the URL Locator and displays the image in the applet. The
`Image Downloader ensures that all pixels of the image are re-
`trieved and displayed properly.
`
`Image Processor: which processes the currently displayed
`image using the image filter selected by the user. Processing
`an image manipulates the pixel values of the image to create
`and display a new image.
`
`Image Uploader: which uploads the currently displayed im-
`age to the server from where the applet was downloaded
`from.1 The Image Uploader generates a GIF-format for the
`currently displayed image and writes the data to the server.
`This allows the user to save processed images persistently at
`the server.
`
`Filter Configurator: which downloads image filters from
`the Server and configures them in the applet. The Filter Con-
`figurator uses the Service Configurator pattern [6] to dynami-
`cally configure the image filters.
`
`2.5.2 JAWS
`
`JAWS is a high-performance, multi-threaded, HTTP Web
`Server [11]. For the purposes of MedJava, JAWS stores the
`MedJava client applet, the image filter repository, and the im-
`ages. The MedJava client applet uses the image filter repos-
`itory to download specific image filters. Each image filter is
`a Java class that can be downloaded by MedJava. This design
`allows MedJava applets to be dynamically configured with im-
`age filters, thereby making image filter configuration highly
`flexible.
`In addition, JAWS supports file uploading by implementing
`the HTTP PUT method. This allows the MedJava client ap-
`plet to save processed images persistently at the server. JAWS
`implements other HTTP features (such as CGI bin and per-
`sistent connections) that are useful for developing Web-based
`systems.
`Figure 4 illustrates the interaction of MedJava and JAWS.
`The MedJava client applet is downloaded into a Web browser
`from the JAWS server. Through GUI interactions, a radiolo-
`gist instructs the MedJava client applet to retrieve images from
`JAWS (or other servers across the network). The requester is
`
`

`

`Receiver
`
`2: pull(image_name)
`
`JAWS
`Server
`
`3: image
`
`ATM
`SWITCH
`
`IMAGE
`STORE
`
`1: push(image)
`
`Sender
`
`Figure 5: Blob Streaming Framework
`
`communicate with Web servers that implement the HTTP PUT
`method to upload images from the browser to the server.
`Although Blob Streaming supports both image download-
`ing and image uploading across the network, its use within a
`Java applet is restricted due to applet security mechanisms. To
`prevent security breaches, Java imposes certain restrictions on
`applets. For example, a Java applet can not write to the local
`file system of the local machine it is running on. Similarly, a
`Java applet can generally download files only from the server
`where the applet was downloaded. Likewise, a Java applet
`can only upload files to the server where the applet was down-
`loaded.
`Java applets provide an exception to these security restric-
`tions, however. In particular, the Java Applet class provides
`a method that allows an applet to download images from any
`server reachable via a URL. Since the method is defined in the
`Java Applet class, it allows Java to ensure there are no secu-
`rity violations. MedJava uses this Applet method to down-
`load images across the network. Therefore, images to be pro-
`cessed can reside in a file system managed by the HTTP Server
`from where the MedJava client applet was downloaded or can
`reside on some other server in the network. However, Blob
`Streaming can only be used to upload images to the server
`where the MedJava applet was downloaded.
`
`2.5.4 Java ACE
`
`Java ACE [5] is a port of the C++ version of the ADAPTIVE
`Communication Environment (ACE) [15]. ACE is an OO net-
`
`6
`
`work programming toolkit that provides reusable components
`for building distributed applications. Containing 125,000
`lines of code, the C++ version of ACE provides a rich set of
`reusable C++ wrappers and framework components that per-
`form common communication software tasks portably across
`a range of OS platforms.
`The Java version of ACE Contains 10,000 lines of code,
`which is over 90% smaller than the C++ version. The reduc-
`tion in size occurs largely because the JVM provides most of
`the OS-level wrappers necessary in C++ ACE. Despite the re-
`duced size, Java ACE provides most of the functionality of
`the C++ version of ACE, such as event handler dispatching,
`dynamic (re)configuration of distributed services, and support
`for concurrent execution and synchronization. Java ACE im-
`plements several key design patterns for concurrent network
`programming, such as Acceptor and Connector [16] and Ac-
`tive Object [17]. This makes it easier to developing network-
`ing applications using Java ACE easier compared to program-
`ming directly with the lower-level Java APIs.
`Figure 6 illustrates the architecture and key components in
`Java ACE. MedJava uses several components in Java ACE. For
`
`DISTRIBUTED
`SERVICES AND
`COMPONENTS
`
`FRAMEWORKS
`AND CLASS
`CATEGORIES
`
`TOKEN
`SERVER
`
`LOGGING
`SERVER
`
`NAME
`SERVER
`
`TIME
`SERVER
`
`ACCEPTOR
`
`CONNECTOR
`
`SERVICE
`HANDLER
`
`ADAPTIVE SERVICE EXECUTIVE (ASX)
`
`JAVA
`WRAPPERS
`
`SYNCH
`WRAPPERS
`
`SOCK_SAP
`
`THREAD
`MANAGER
`
`LOG
`MSG
`
`TIMER
`QUEUE
`
`SERVICE
`CONFIGURATOR
`
`JAVA VIRTUAL MACHINE (JVM)
`
`Figure 6: The Java ACE Framework
`
`example, Java ACE provides an implementation of the Service
`Configurator pattern [6]. MedJava uses this pattern to dynam-
`ically configure and reconfigure image filters. Likewise, Med-
`Java uses Java ACE profile timers to compute performance in
`benchmark mode.
`
`3 Performance Benchmarks
`
`This section presents the results of performance benchmarks
`conducted with the MedJava image processing system. We
`performed the following two sets of benchmarks:
`
`1. Image processing performance: We measured the per-
`formance of MedJava to determine the overhead of using Java
`for image processing. We compared the performance of our
`MedJava applet with the performance of xv. Xv is a widely-
`used image processing application written in C. The MedJava
`
`

`

`image process applets are based on the xv algorithms.
`
`2. High-speed networking performance: We measured the
`performance of using Java sockets over a high-speed ATM net-
`work to determine the overhead of using Java for transporting
`data. We compared the network performance results of Java to
`the results of similar tests using C/C++.
`
`Below, we describe our benchmarking testbed environment,
`the benchmarks we performed, and the results we obtained.
`
`3.1 MedJava Image Processing Benchmarks
`
`We benchmarked MedJava to compare the performance of
`Java with xv, which is a widely-used image processing appli-
`cation written in C. Xv contains a broad range of image filters
`such as Blur, Sharpen, and Emboss. By applying a filter to an
`image in xv, and then applying an equivalent filter algorithm
`written in Java to the same image, we compared the perfor-
`mance of Java and C directly. In addition, we benchmarked
`the performance of different Web browsers running the Med-
`Java applet.
`
`3.1.1 Benchmarking Testbed Environment
`
`Hardware Configuration: To study the performance of
`MedJava, we constructed a hardware and software testbed
`consisting of a Web server and two clients connected by Ether-
`net, as shown in Figure 7. The clients in our experiment were
`
`WWW
`Server
`
`

`

`value for the pixel is: value(cid:0)p mean value
`
`

`

`operation
`
`NS 4
`
`IE 4
`
`IE 4 JIT off
`
`

`

`operation
`
`MSVC++ output
`
`Naturally, when invoking methods internal to a class, this is
`not a problem. Moreover, the -O option on the Sun javac
`source to bytecode compiler requests that it attempt to inline
`methods.
`As an example of worthwhile manual method in-
`lining,
`an ImageFilter contains a method called
`setColorModel.
`In this method the ImageProducer
`provides the ImageFilter with the ColorModel subclass
`that grabs the color values of each pixel in the image source.
`ColorModel is an abstract class with methods getRed,
`getGreen, and getBlue to retrieve the specific color value
`from each pixel. Thus, every time a filter needs a color value, it
`must incur the overhead of this dynamically resolved method
`call. However, calling the getDefaultColorModel static
`method on ColorModel returns a ColorModel subclass,
`which guarantees that each pixel will be in a known form,
`where the first 8 bits are the alpha (transparency) value, the
`next 8 are the red, the next 8 are the green, and the last
`8 bits are the blue value. Therefore, rather than using the
`methods on ColorModel to retrieve the color values, the
`ImageFilter can retrieve values simply by shifting and
`masking the integer value of the pixel, e.g., to obtain the red
`value of a pixel: (pixel >> 16) & 0xff.
`Of course, for C code many of the same optimization tech-
`niques apply. We ran a similar set of operation benchmarks in
`C, using the same test harness technique as we did for the Java
`benchmarks. The results, shown in Table 2, are the mean of 5
`trials, with each measurement exhibiting a standard deviation
`of no more than 0.5 nanoseconds.
`With “global optimizations” enabled, the MSVC++ com-
`piler will actively assign variables to registers at its own dis-
`cretion. With optimizations disabled, it takes no special mea-
`sures to abide by the register keyword. Again, the results
`are listed in nanoseconds.
`Table 2 reveals that the MSVC++ generated code yields
`comparable performance with the output of the two JIT com-
`pilers. Narrowing casts, for example from floating point to
`integer data is more time consuming in the MSVC++ gener-
`ated code than the JIT output, however, calls to static, exter-
`nal, and library functions (e.g., rand) are less time consuming
`than their Java method equivalents. Also, floating point multi-
`plication and division, translated into the fmul and fdiv in
`MSVC++, lag behind the JIT translation of these operations.
`
`3.1.4 Performance Results and Evaluation
`
`Figures 9–16 plot our results for each of the eight filters on
`each of the three language/compiler permutations.
`Using insights about the most frequently performed opera-
`tions in the algorithms, and the tables enumerating the costs
`of those operations on the three configurations (Tables 1 and
`2), we can attempt to explain any observed, counter-intuitive
`
`

`

`NS 4.0 JIT
`IE 4.0 JIT
`xv (both, level 2 opts)
`
`200000
`
`400000
`
`800000
`600000
`Image Size (number of pixels)
`
`1000000 1200000 1400000
`
`5000
`
`4500
`
`4000
`
`3500
`
`3000
`
`2500
`
`2000
`
`1500
`
`1000
`
`500
`
`Processing Time (milliseconds)
`
`0
`
`0
`
`NS 4.0 JIT
`IE 4.0 JIT
`xv (both, level 2 opts)
`
`200000
`
`400000
`
`800000
`600000
`Image Size (number of pixels)
`
`1000000 1200000 1400000
`
`3000
`
`2500
`
`2000
`
`1500
`
`1000
`
`500
`
`Processing Time (milliseconds)
`
`0
`
`0
`
`Figure 10: Comparative Performance of the Java-enabled
`Browsers and xv in Applying the Edge Detection Image Filter
`to an Image at Various Sizes
`
`Figure 13: Comparative Performance of the Java-enabled
`Browsers and xv in Applying the Oil Paint Image Filter to
`an Image at Various Sizes
`
`NS 4.0 JIT
`IE 4.0 JIT
`xv (both, level 2 opts)
`
`200000
`
`400000
`
`800000
`600000
`Image Size (number of pixels)
`
`1000000 1200000 1400000
`
`8000
`
`7000
`
`6000
`
`5000
`
`4000
`
`3000
`
`2000
`
`1000
`
`Processing Time (milliseconds)
`
`0
`
`0
`
`xv (both, level 2 opts)
`xv (both, level 1 opts)
`NS 4.0 JIT
`IE 4.0 JIT
`
`200000
`
`1000000 1200000 1400000
`800000
`600000
`400000
`Image Size (number of pixels)
`
`2500
`
`2000
`
`1500
`
`1000
`
`500
`
`Processing Time (milliseconds)
`
`0
`
`0
`
`Figure 11: Comparative Performance of the Java-enabled
`Browsers and xv in Applying the Blur Image Filter to an Im-
`age at Various Sizes
`
`Figure 14: Comparative Performance of the Java-enabled
`Browsers and xv in Applying the Spread Image Filter to an
`Image at Various Sizes
`
`IE 4.0 JIT
`NS 4.0 JIT
`xv (both, level 2 opts)
`
`200000
`
`400000
`
`800000
`600000
`Image Size (number of pixels)
`
`1000000 1200000 1400000
`
`600
`
`500
`
`400
`
`300
`
`200
`
`100
`
`Processing Time (milliseconds)
`
`0
`
`0
`
`NS 4.0 JIT
`IE 4.0 JIT
`xv (both, level 2 opts)
`
`200000
`
`400000
`
`800000
`600000
`Image Size (number of pixels)
`
`1000000 1200000 1400000
`
`3000
`
`2500
`
`2000
`
`1500
`
`1000
`
`500
`
`Processing Time (milliseconds)
`
`0
`
`0
`
`Figure 12: Comparative Performance of the Java-enabled
`Browsers and xv in Applying the Despeckle Image Filter to
`an Image at Various Sizes
`
`Figure 15: Comparative Performance of the Java-enabled
`Browsers and xv in Applying the Emboss Image Filter to an
`Image at Various Sizes
`
`11
`
`

`

`3.2.1 Benchmarking Configuration
`Benchmarking testbed: The network benchmarking tests
`were conducted using a FORE systems ASX-1000 ATM
`switch connected to two dual-processor UltraSPARC-2s run-
`ning SunOS 5.5.1. The ASX-1000 is a 96 Port, OC12 622
`Mbs/port switch. Each UltraSparc-2 contains two 168 MHz
`Super SPARC CPUs with a 1 Megabyte cache per-CPU. The
`SunOS 5.5.1 TCP/IP protocol stack is implemented using the
`STREAMS communication framework. Each UltraSparc-2 has
`256 Mbytes of RAM and an ENI-155s-MF ATM adaptor card,
`which supports 155 Megabits per-sec (Mbps) SONET multi-
`mode fiber. The Maximum Transmission Unit (MTU) on the
`ENI ATM adaptor is 9,180 bytes. Each ENI card has 512 Kbytes
`of on-board memory. A maximum of 32 Kbytes is allotted per
`ATM virtual circuit connection for receiving and transmitting
`frames (for a total of 64 K). This allows up to eight switched
`virtual connections per card.
`
`Performance metrics: To evaluate the performance of Java,
`we developed a test suite using Java ACE. To measure the
`performance of C/C++ as a transport interface, we used an
`extended version of TTCP protocol benchmarking tool [22].
`This TTCP tool measures the throughput of transferring un-
`typed bytestream data (i.e., Blobs [14]) between two hosts.
`We chose untyped bytestream data, since untyped bytestream
`traffic is representative of image pixel data, which need not be
`marshaled or demarshaled.
`
`3.2.2 Benchmarking Methodology
`
`We measured throughput as a function of sender buffer size.
`Sender buffer size was incremented in powers of two ranging
`from 1 Kbytes to 128 Kbytes. The experiment was carried out
`ten times for each buffer size to account for variations in ATM
`network traffic. The throughput was then averaged over all the
`runs to obtain the final results.
`Since Java does not allow manipulation of the socket queue
`size, we had to use the default socket queue size of 8 Kbytes
`on SunOS 5.5. We used this socket queue size for both the
`Java and the C/C++ network benchmarking tests.
`
`NS 4.0 JIT
`IE 4.0 JIT
`xv (both, level 2 opts)
`
`400
`
`350
`
`300
`
`250
`
`200
`
`150
`
`100
`
`50
`
`0
`
`Processing Time (milliseconds)
`
`0
`
`200000
`
`400000
`
`800000
`600000
`Image Size (number of pixels)
`
`1000000 1200000 1400000
`
`Figure 16: Comparative Performance of the Java-enabled
`Browsers and xv in Applying the Pixelize Image Filter to an
`Image at Various Sizes
`
`differences in the performance of the algorithms.
`In general, the hand-optimized Java algorithms executed in
`times comparable with their C hand-optimized counterparts.
`However, the added benefit of the MSVC++ compile-time op-
`timizations gave the C algorithms a competitive advantage.
`Thus, for all but two of the filters (Blur image filer and Sharpen
`image filter), the C algorithms outperformed their Java equiv-
`alents.
`Contributing to the overall superiority of the C algorithm
`execution is fast array access time and increments, induced
`by the rigorous utilization of registers by the compiler. How-
`ever, applying the techniques of code movement and strength
`reduction help the Java code to negate any benefits of similar
`compile-time optimization performed by the C/C++ compiler.
`There is one severely aberrational case in which the C run-
`time performed more poorly than the Java ones: the sharpen
`filter. In the sharpen filter, color values are continually con-
`verted between the integer RGB format and the floating point
`HSV format. Netscape, whose floating point to integer nar-
`rowing conversion performance exceeds Internet Explorer’s
`and C/C++’s, has the competitive advantage.
`
`3.2 High-speed Network Benchmarking
`
`As described earlier, high performance is one of the key forces
`that guides the development of a distributed EMIS. In particu-
`lar, it is important that medical images be delivered to radiol-
`ogists and processed in a timely manner to allow proper diag-
`nosis of patients exams. To evaluate the performance of Java
`as a transport interface for exchanging large images over high-
`speed networks, we performed a series of network benchmark-
`ing tests over ATM. This section compare