1 / 18

Compressibility of WML and WMLScript byte code:Initial results

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. Outline. Introduction Experimental Compression Results

owena
Télécharger la présentation

Compressibility of WML and WMLScript byte code:Initial results

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

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 ofWML and WMLScript byte code • Conclusions

  3. Introduction • In this paper,it examine how much the byte codeused in the WAP environment can be compressedand whether the reduced transmission time warrantsthe 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 codegenerated from WML can be compressed to such anextent that possibly real compression mechanismsat terminals and servers are feasible. • We just took a few well-known algorithms and rantests 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 savingscan 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 asthe source file size drops below approx. 300 bytes.

  6. As the average of our test filesis merely 416 bytes,the gziptest resulted in only 9%gainin 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 requiremultiplication and division operations that might be too slowor power consuming to be used in WAP terminals. • The ELS approach is purely integer-based and thus bettersuited 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 eachcompressed file.

  8. Practical relevance of compression ofWML 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 applicationdoes 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 and320 bytes.The situation changes!

  9. Practical relevance of compression ofWML 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 theserver. • 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 relyon the decompression algorithm. • The compressed byte code is so large that it requiresseveral messages to be transferred. • The point where both compressed and uncompressedcase 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=9i.e,for file size larger than 9 compression blocks,the responsetime 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 decompressiondepends 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 fordecompression 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 interminal.

  16. Time and space complexity and energy consumption • Some versions of LZ algorithms have linear time complexityboth for compression and decompression. • Energy consumption grows with the time complexity. • The trade-off between decreased energy consumption ofthe RF-parts and increased energy consumption of the processor can’t be easily assessed without more accurateparameter 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 makescompression more attractive.

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

More Related