When designing the storage management for my XML tools
(especially the SAX and DOM parsers), I had the following goals
in mind:
- to support many allocation and free calls of little storage areas
- to reuse the areas of the same size without much lookup time
- to separate the areas from other allocations, that are done outside
the XML tools
- and: to be able to get rid of all the areas at the end of the XML
parsing etc.
in a simple and secure way.
So I put some storage management functions of my own on top of the normal
malloc/free (or any other storage management provided by the customer,
which provides a similar interface as malloc/free).
Now I wanted to know, which additional overhead is created by using my
storage functions instead of the original malloc/free - or: if there is
any.
Of couse, if could be, because I'm doing some work to arrive at the
goals outlined above.
I had no chance to test on the mainframe, at the moment, but I tried it
on OS/2, Linux (Intel) and Windows. I parsed a 23 MB XML document
with validation. The OS/2 and Linux hardware is a very old Pentium processor
(from 1999), the Windows hardware a some years old Dell laptop.
I parsed the XML the first time with my storage management, and the
second time
with normal malloc/free functions.
Here the results:
on OS/2, original malloc/free is 2 to 3 percent faster than with my storage
management; the parsing needs 19 seconds
on Linux, it' different; my storage management is about 2 to 3 percents
faster,
the parsing needs only 17 seconds (same hardware)
on Windows, my storage management is 1 percent faster, the parsing
needs only 3.8 seconds - with the contemporary hardware, of course
(I confirmed this by parsing the XML 10 times, because with only 1 run
the results were not very reliable).
I'm very impressed of the OS/2 storage management, because it seems
to do a very good job. Also the others are not at all bad, because - given
so many allocation calls of little areas - the results are good, IMO.
Anyway: the test shows, that you can still do some improvements
- on Linux and Windows - BY ADDING additional storage management
logic on top of the existing malloc / free functions. I could imagine that
this could be the case on z/OS, too. Of course, this is more important,
if applications do STORAGE OBTAIN or GETMAIN calls directly,
which IMO are far more costly than malloc / free.
I would like to test the same thing on z/OS next week or so, but I first
have to talk to my customer about this. At the moment, my customer
uses very costly site-specific software allocation functions; the routine,
which does the storage management, needs several percents of the
overall CPU time in certain situations; this is due to the fact that the
areas are stored in linked lists and checked (sequentially) for errors
at certain points in time. I will try to convince my customer to do some
improvements here (for example, by putting my software management
functions on top of the site-specific functions).
Kind regards
Bernd
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
