Redim computationally expensive?

[Kate]

I have some 2-4D arrays that are filled by several different subs.
Instead of maintaining a global or module level counter, I'd rather
redim the array after each sub is finished, and start the next sub out
at ubound(ary).

The program is already getting sluggish and I'm looking for ways to
improve performance--is redimming the arrays adding an unnecessary
load?

BTW, if anyone has some good ways to investigate which parts of the
program are dragging it down, I'd appreciate any advice. I don't have
a performance monitor.
I'm using several data source/data consumer classes, but the
performance doesn't degrade more as I add more of those (or add more
datamembers to them), so I'm not sure if that's the problem.

Thanks--

[Steve Gerrard]

"Kate" <ka**@curio.com> wrote in message
news:2c**************************@posting.google.c om...

I have some 2-4D arrays that are filled by several different subs.
Instead of maintaining a global or module level counter, I'd rather
redim the array after each sub is finished, and start the next sub out
at ubound(ary).

The program is already getting sluggish and I'm looking for ways to
improve performance--is redimming the arrays adding an unnecessary
load?

BTW, if anyone has some good ways to investigate which parts of the
program are dragging it down, I'd appreciate any advice. I don't have
a performance monitor.
I'm using several data source/data consumer classes, but the
performance doesn't degrade more as I add more of those (or add more
datamembers to them), so I'm not sure if that's the problem.

Thanks--

Redim-Preserve an array means allocating a new, bigger block of memory,
copying the old block to the new block, and releasing the old block.
Whether that is a performance hit depends on how big the array is, how
much memory is available, and how the time involved compares to whatever
else you are doing. Several larger redims are usually preferable to lots
of smaller redims.

If you are using data sources, you might want to see whether retrieving
data is the main slow down, compared to array processing. It often is,
since it is disk/network intensive. As far as how to monitor, start with
a few Debug.Print "starting process X at " & Now and Debug.Print
"finished process X at " & Now, and then look harder at the processes
that take too long.

We always enjoy seeing some code and offering opinions on which bits
could be tweaked for performance...:)

[Kate]

> > The program is already getting sluggish and I'm looking for ways to

improve performance--is redimming the arrays adding an unnecessary
load?

BTW, if anyone has some good ways to investigate which parts of the
program are dragging it down, I'd appreciate any advice.

Redim-Preserve an array means allocating a new, bigger block of memory,
copying the old block to the new block, and releasing the old block.
Whether that is a performance hit depends on how big the array is, how
much memory is available, and how the time involved compares to whatever
else you are doing. Several larger redims are usually preferable to lots
of smaller redims.

If you are using data sources, you might want to see whether retrieving
data is the main slow down, compared to array processing. It often is,
since it is disk/network intensive. As far as how to monitor, start with
a few Debug.Print "starting process X at " & Now and Debug.Print
"finished process X at " & Now, and then look harder at the processes
that take too long.

We always enjoy seeing some code and offering opinions on which bits
could be tweaked for performance...:)

Really? From reading other posts, I had the impression nobody could
help me this way. How/to whom do I post it, and how should I
discriminate about the relevant bits? See, here's the deal: I had a
big messy program to clean up, and I learned a bit about component
design and using VB data sources/consumers as I was fixing the
program. So there is a bit of a mish-mash here (e.g., in one "half" of
the program--the drawing half--I made complex-bound data consumer
classes. In the second half, I dispensed with that and just used the
sources, since it seemed a bit less unwieldy. Now I'm wondering which
half might be in need of more tuning-up.)

[Larry Serflaten]

"Kate" <ka**@curio.com> wrote

We always enjoy seeing some code and offering opinions on which bits
could be tweaked for performance...:)

Really? From reading other posts, I had the impression nobody could
help me this way. How/to whom do I post it, and how should I
discriminate about the relevant bits?

Isolate the problemed code. Make a small demo that demonstrates the
problems so that they can be reproduced on the systems of those who
would offer help.

Often times, while creating the demo, you can find the mistakes, or
clean up the code, to eliminate the problems. If not, you still have a
short demo you can post for others to try out.

Very few are going to want to look at several forms, half a dozen modules
and classes just to find a problem in one small area of a program. We
often need to see the actual code that causes the problem, to know what
the cause is, and especially to see where improvements might be offered.

LFS


-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 100,000 Newsgroups - 19 Different Servers! =-----

[J French]

On 21 Jan 2004 05:44:21 -0800, ka**@curio.com (Kate) wrote:

<snip>

Really? From reading other posts, I had the impression nobody could
help me this way. How/to whom do I post it, and how should I
discriminate about the relevant bits? See, here's the deal: I had a
big messy program to clean up, and I learned a bit about component
design and using VB data sources/consumers as I was fixing the
program. So there is a bit of a mish-mash here (e.g., in one "half" of
the program--the drawing half--I made complex-bound data consumer
classes. In the second half, I dispensed with that and just used the
sources, since it seemed a bit less unwieldy. Now I'm wondering which
half might be in need of more tuning-up.)

Your posts have been too vague for us to latch on to.

However one general bit of advice seems appropriate
- apply 'Occam's Razor'

Remove and fake bits until you see things improving
- collect data and then release a routine on a command button

Repeat that for all small parts of the App

When you find the bottleneck - post again
- but the chances are you will not need to - it will be obvious