Presentation is loading. Please wait.

Presentation is loading. Please wait.

Compressibility of WML and WMLScript byte code:Initial results Eetu Ojanen and Jari Veijalainen Department of Computer Science and Information Systems.

Similar presentations


Presentation on theme: "Compressibility of WML and WMLScript byte code:Initial results Eetu Ojanen and Jari Veijalainen Department of Computer Science and Information Systems."— Presentation transcript:

1 Compressibility of WML and WMLScript byte code:Initial results Eetu Ojanen and Jari Veijalainen Department of Computer Science and Information Systems University of Jyvaskyla Finland

2 Outline Introduction Experimental Compression Results Practical relevance of compression of WML and WMLScript byte code Conclusions

3 Introduction In this paper,it examine how much the byte code used in the WAP environment can be compressed and whether the reduced transmission time warrants the increased memory and processor overhead caused by the compression and decompression. WMLScript: scripting language similar to JavaScript. The WML contents and WMLScript applications are compiled into WML Byte code before interpretation.

4 Experimental Compression Results The main purpose is to check,whether the byte code generated from WML can be compressed to such an extent that possibly real compression mechanisms at terminals and servers are feasible. We just took a few well-known algorithms and ran tests with them. The test data Consist of about 90 files. Small size of byte code files: 18 ~ 1374 bytes 416 bytes in average.

5 Experimental Compression Results According to the principles of the compression algorithms: the bigger code files,the bigger savings can be achieved by compression. The algorithms and results Considering only lossless compression algorithm. Comparing gzip,bzip2, ELS coding,BWT and MTF. gzip: LZ 77,a dictionary-based coding algorithm. The gzip starts to rapidly increase the result file size as the source file size drops below approx. 300 bytes.

6 As the average of our test files is merely 416 bytes,the gzip test resulted in only 9% gain in average. CR=original /Compressed (size) Gain = 1-(1/CR)

7 Experimental Compression Results Arithmetic coding v.s ELS(Entropy Logarithmic Scale) The implementations of arithmetic coding often require multiplication and division operations that might be too slow or power consuming to be used in WAP terminals. The ELS approach is purely integer-based and thus better suited for environment with very limited CPU resources. Both gzip and bzip2 write file headers(with CRCs, platform information etc.) that always require a certain amount of space in the beginning of each compressed file.

8 Practical relevance of compression of WML and WMLScript byte code The effect of bearers on the feasibility of compression. Do compression improve performances or save resources? Example : Sending a GSM short message. Because a short message has fixed size length,160 characters, sending the same byte code compressed for this application does not reduce response time. Compression makes the overall turn-around time longer. Transmission cost : the same for compression and uncompr. If the length of the byte code is uncompressed between 161 and 320 bytes.The situation changes!

9 Practical relevance of compression of WML and WMLScript byte code Compress the code so that it fits into one short message. Shorten the time waiting for application to run. Makes transaction cheaper. It makes sense from customer ’ point of view. The same conclusion holds for HSCSD, and GPRS. From the mobile operator ’ s point of view Compression decreases the number of short messages. Saving bandwidth and storage disk space.

10 Turn-around time for sequential data transfer and decompression Assuming that the data is stored compressed at the server. Size(AC): size of the application AC in bytes. Speed_tr: average transfer speed of the network from server to client in bytes/s. Speed_dec: average decompression speed at the terminal. CR: compression ratio.

11 Turn-around time for sequential data transfer and decompression We assume that the decompression speed only rely on the decompression algorithm. The compressed byte code is so large that it requires several messages to be transferred. The point where both compressed and uncompressed case yield the same response time.

12 Turn-around time for sequential data transfer and decompression It relates the compression ratio and the diverse speeds. Eg1: cr=0.5, Speed_tr=Speed_dec. It means that the terminal is able to decompress the data with the same speed as it is transferred,in order not to slow down the system from uncompressed case. Eg2: cr=0.1, Speed_dec is about ten times faster than the Speed_tr.

13 Pipelining data transfer and decompression Data is transferred and decompressed in parallel. The terminal uses two buffers to transfer and decompress the data. Assume there are N blocks,N>1 Eg: cr=0.9, Speed_dec=Speed_tr, ->N=9 i.e,for file size larger than 9 compression blocks,the response time is shorter than for an uncompressed case.

14 Pipelining data transfer and decompression If, the equation is Letting the ratio of two speed approach 1, the limit would be the same as the previous Eq.

15 Time and space complexity and energy consumption The time and space complexity of decompression depends on the decompression algorithm. The practical amount of memory might be around 10-20kB, for the LZ variants. It is observed that LZB variant only need 8kB memory for decompression and reached 16kB/s speed. Nokia 7110 has almost 1MB RAM for application and data. If the estimate is correct then WAP terminals shoould be able to cope with the decompression. The decompressor code can be placed into a ROM in terminal.

16 Time and space complexity and energy consumption Some versions of LZ algorithms have linear time complexity both for compression and decompression. Energy consumption grows with the time complexity. The trade-off between decreased energy consumption of the RF-parts and increased energy consumption of the processor can ’ t be easily assessed without more accurate parameter values of the terminal.

17 Conclusion We have analyzed under which conditions the response time would not increase due to the time used to decompress the data. In average,the compression ratio in the sample was about 1.5 and the larger file the higher compression ratio. While applications tend to be larger in size, it makes compression more attractive.

18 Conclusion Our test material did not contain any images, since the compression method can ’ t be applied to both. It is foreseen that WBMP format for WAP images would be compressed with a special algorithm.


Download ppt "Compressibility of WML and WMLScript byte code:Initial results Eetu Ojanen and Jari Veijalainen Department of Computer Science and Information Systems."

Similar presentations


Ads by Google