[log in to unmask] said:
> I appreciated that you were just supplying representative code.
> However if it is possible to avoid dynamic allocation, then you
> generally get better performance. Of course, if you want the
> convenience, it comes at a price at run time (as with most things in
> life!).
Personally, I have a hard time to understand why dynamic allocation
of a large module variable would have any noticeable performance
difference as to a variable statically allocated in a module or a
common block in any respect besides the time it takes to allocate and
deallocate the variable.
A friendly compiler could of course add extra code to check the
availability of the variable and its size when the code is compiled
with array bounds checking enabled (-C) or with optimization explicitly
trunde off (-O0). Adding any such code at default compiler option level
would only state that the vendor of the compiler doesn't trust the product.
If there is something inherent in the computer architecture that or
compiler structure that says that I am wrong, please inform me.
There are side issues of course. Passing an assumed _shape_ array would
sometimes require a slightly increased number of integer operations to
compute array offsets. If the arrays concerned are involved in integer
arithmetic themselves I would expect a related performance decrease due to
limited integer unit resources. When using dynamic allocation the
programmer could be more inclined to use assumed _shape_. My experience
(although not well investigated) is that today's compilers handle assumed
shape well at higher optimization levels, so I would hope that this
not a big issue either.
I am happy to be convinced that I am worng. Ok, not happy, but I might
accept it...
/Nils
|