Hi
We had something similar, a heap mgmt system in all the possible platforms,
I don't know now the result from the other platforms but , in z/OS the
HEAPPOOLS(align,... ) was the best .
On 06.07.2013 17:57, Bernd Oppolzer wrote:
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
--
Kind regards, / Mit freundlichen Grüßen
Miklos Szigetvari
Research& Development
ISIS Papyrus Europe AG
Alter Wienerweg 12, A-2344 Maria Enzersdorf, Austria
T: +43(2236) 27551 333, F: +43(2236)21081
E-mail: [email protected]
Info: [email protected] Hotline: +43-2236-27551-111
Visit our brand new extended Website at www.isis-papyrus.com
---------------------------------------------------------------
This e-mail is only intended for the recipient and not legally
binding. Unauthorised use, publication, reproduction or
disclosure of the content of this e-mail is not permitted.
This email has been checked for known viruses, but ISIS Papyrus accepts
no responsibility for malicious or inappropriate content.
---------------------------------------------------------------
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
