home *** CD-ROM | disk | FTP | other *** search
/ OS/2 Shareware BBS: 8 Other / 08-Other.zip / timetest.zip / readme.txt
Text File  |  1997-05-24  |  7KB  |  158 lines
  1.  
  2. Performance test of Open32 using Delphi and VP/2
  3.  
  4. by Allan Mertner, 23 May 1997
  5.  
  6.  
  7. fPrint (UK) Ltd recently released a new version of Virtual Pascal for
  8. OS/2 that provides compatibility with Borland Delphi.  Using this
  9. compiler, I have done a performance test of the code output by the OS/2
  10. compiler and compared it against the performance on native Windows.
  11.  
  12. The results confirm what has been common knowledge for a while: The
  13. Open32 library IBM supplies for making it easy to convert Windows
  14. applications to the OS/2 platform is both buggy and slow.
  15.  
  16. The Delphi source code for the program used for testing is included in
  17. the SRC directory of this archive.  The source compiles with Borland
  18. Delphi v1 or v2, or Virtual Pascal for OS/2.  In other words, the same
  19. source code produces executables for Win16, Win32 and 32-bit OS/2.
  20.  
  21. The resulting 3 executables can be found in the EXE subdirectory, and
  22. are called TESTOS2.EXE, TESTW32.EXE and TESTW16.EXE, respectively.
  23.  
  24.  
  25. Executable sizes
  26.  
  27. First off, don't put too much into the size of the 3 executables.  The
  28. OS/2 version is smallest because it is compressed using OS/2's built-in
  29. ExePack 2 compression; if it was uncompressed, the size would be 266kB
  30. instead of the 165kB it is in this archive.  Windows does not offer a
  31. similar feature, so we obviously end up with larger executables.
  32.  
  33.  
  34. What the test does
  35.  
  36. The test is very simple: I draw some labels on a form, and count how
  37. often I can do it.  The test program has two "modes" of test.  In the
  38. first mode, the program hooks the IDLE message and updates the labels
  39. every time the operating system is idle.  In the second mode, I simply
  40. update the labels as many times as possible in 10 seconds.
  41.  
  42. For the benchmark results, I used the second test to rule out any
  43. differences in idle processing between the operating systems, although
  44. the results were almost identical.
  45.  
  46. The scores listed below are a simple count of the number of updates the
  47. program made per second during the run.
  48.  
  49.  
  50. Executable speed
  51.  
  52. The exciting bit comes when trying to run the programs in various
  53. operating systems.  The Win32 executable runs in both Windows 95 and NT,
  54. the Win16 one runs in both NT, 95, Win3.x and WinOS/2, and the OS/2 one
  55. of course runs only in OS/2.
  56.  
  57. Each executable was run on the machines I have available, with nothing
  58. running in the background.  I ran each program 3 times and took the
  59. highest score achieved - the results are as follows:
  60.  
  61. On my Pentium Pro 200, with a Number Nine I128 graphics card and 32MB of
  62. memory, the results were:
  63.  
  64.   Operating System   Executable Version    Result (higher is better!)
  65.   Windows NT 4       Win32                 448
  66.   Windows 95         Win32                 411
  67.   Windows 95         Win16                 404
  68.   Windows NT 4       Win16                 291
  69.   OS/2 Warp 4        OS/2                  48
  70.  
  71. On my older box, a 486 DX/2 66 with an ATI Mach 32 card and also 32MB of
  72. memory, the results were (Limited by OS's available :)
  73.  
  74.   Operating System   Executable Version    Result (higher is better!)
  75.   WinOS/2 v3.11      Win16                 91
  76.   OS/2 Warp 4        OS/2                  9
  77.  
  78. In summary, the OS/2 version is quite slow, NT is fastest at executing
  79. Win32 programs, and '95 is fastest at executing 16-bit ones.  This is
  80. not surprising, but it certainly is surprising to me that the OS/2
  81. version running on a Pentium Pro 200 is half as fast as the Win16
  82. version running in WinOS/2 on a 486/66!
  83.  
  84. The "Benchmark" tab of the notebook in the program also contains these
  85. results in a string grid.  If you switch to this page and then run the
  86. test, you can see how fast the labels are updated when they are not
  87. visible :)
  88.  
  89.  
  90. Program looks
  91.  
  92. The OS/2 version of the program suffers from a number of visual
  93. problems.  Although it works and does its job, it is visually
  94. unappealing.  The main problems are to do with
  95.  * colour mapping (the background is white in places),
  96.  * bitmap drawing (the tabs on the notebook control are drawn in the
  97.    wrong colour due to a known bug in Open32's BitBlt function),
  98.  * font translation (try to use an Ms Sans Serif font in a program :),
  99.  * font clipping (for some reason, the fonts are generally larger in
  100.    OS/2 than in Windows.  This means that the text is clipped in places,
  101.    if the default rectangle sizes from Windows are in place.  IBM claims
  102.    this is a programming error, not a bug in Open32),
  103.  * speed.  I think I've covered that adequatly.
  104.  
  105. The font clipping problem can sometimes be worked around by manually
  106. sizing all labels to be a bit higher and wider than default.  To
  107. demonstrate this, the test program contains both an "Autosize" and a
  108. "ManualSize" tab containing the same text.
  109.  
  110.  
  111. Discussion
  112.  
  113. IBM needs to work on their Open32 library!  They need to hire developers
  114. that care about code quality, both in terms of functionality and in
  115. terms of speed.  A 10% or even 50% increase in speed is *not* good
  116. enough; an increase by a factor of 8 would make a difference.
  117.  
  118. It is extremely unlikely that IBM will dedicate the resources required
  119. to do this however.  Open32 has shown its usefulness as a technology
  120. demonstration, nothing more - applications using it are obviously
  121. inferior to programs that use a native API.
  122.  
  123. The really frustrating part about Open32 is that it is not documented.
  124. When a discrepancy between Open32's behaviour and Windows is uncovered,
  125. it is a tiresome process to report the problem to IBM, provide a test
  126. case for the problem, wait for the lab to look at it, wait for the
  127. problem to become an approved problem, and finally - after several
  128. months - be told that it is a permanent restriction.  If only the
  129. differences and shortcomings were documented, they could be worked
  130. around.  As it is, IBM has released Open32 as a Windows API emulation
  131. library with no restrictions imposed, and it doesn't work.
  132.  
  133. During development of the Virtual Pascal compatible VCL source code (the
  134. VCL is the component class library used by Delphi), we wanted to work
  135. around the problems we found by using native OS/2 API calls in some of
  136. the code, and only rely on Open32 where it actually works.  This also
  137. proved impossible, again mainly due to lack of documentation.  Open32
  138. implements a number of Windows functions, obviously by calling OS/2
  139. functions that do a similar job.  However, all handles and structures
  140. returned by Open32 are Windows equivalents, and no documentation about
  141. the internal structures used by Open32 is available, making it
  142. impossible to make a hybrid solution.
  143.  
  144.  
  145. Finally
  146.  
  147. Thank you for listening - if you have any comments or suggestions, feel
  148. free to e-mail me at mertner@ibm.net.  If you feel it might help, you
  149. can also write to IBM and tell them to do something about Open32 :-)
  150.  
  151. Oh, and the source and executables for the timetest program are hereby
  152. donated to the public domain ;)
  153.  
  154.  
  155. Yours truly,
  156. Allan Mertner
  157.  
  158.