PE> I got cset++/2 about a week ago, in case you're interested.



 PE> The following results are not necessarily representative, and were done

 PE> with a program with heaps of "inline"s, and the optimizer
would have

 PE> spent years trying to optimize it, when they weren't really speed

 PE> critical anyway.  It's worth getting cset++/2, just to watch the compiler

 PE> have to do some hard work. The funny thing is though, that a lot of the

 PE> optimization time was spent on disk access, no idea why.



I meant to buy it while it was on special, but due to a serious lack of
hard disk space, I never got around to it. I've just added a 500 meg SCSI
drive so I have loads of space, but I'm not going to pay $1,000+ for the
compiler.



I don't know why it would be doing so much disk access. It may be writing
out a huge intermidiate file and making multiple passes though it. Or it
could be allocating huge amounts of memory and paging it in and out. Check
out the size of the swap file while it's running.



 PE> 25 seconds to compile non-optimized with cset++/2

 PE> run time 59 seconds

 PE> 60k executable



 PE> 8 minutes 25 seconds for optimized with cset++/2

 PE> run time 38 seconds

 PE> 120k executable



This is just a little bit excessive, although not really surprising in an
IBM product. Maybe you need to buy a faster hard disk :-)



 PE> 9 seconds to compile xword6 optimized with BC++

 PE> run time 41 seconds

 PE> 30k executable



What program were you compiling with the IBM compiler? It obviously isn't
the same one you used with the Borland compiler.



Paul



--- GoldED 2.40