comp.lang.idl-pvwave archive
Messages from Usenet group comp.lang.idl-pvwave, compiled by Paulo Penteado

Home » Public Forums » archive » Re: Minor IDL code changes cause large slowdowns elsewhere in code
Show: Today's Messages :: Show Polls :: Message Navigator
E-mail to friend 
Return to the default flat view Create a new topic Submit Reply
Re: Minor IDL code changes cause large slowdowns elsewhere in code [message #56329 is a reply to message #56297] Wed, 10 October 2007 14:04 Go to previous messageGo to previous message
Haje Korth is currently offline  Haje Korth
Messages: 651
Registered: May 1997
Senior Member
Any difference if you try the comparison with integer numbers assigned to
the tree types? Haje


"cedric" <cedric@barrodale.com> wrote in message
news:1192042534.817071.151580@19g2000hsx.googlegroups.com...
> I have observed a problem in an IDL timber supply model that arose
> after having made some changes to use tables instead of computations
> in order to free up some memory space and to circumvent some involved
> computations. Following these changes, there was a general four-fold
> increase in execution times, even for those sections of code that were
> unaffected by the change. After doing some analysis, I found that
> this was at least partly due to large increases in times for
> operations involving manipulating string fields in a vector of
> structures (with, say, 50,000 elements).
>
> For example, we have a string vector of the form
> (*(*unit[i]).layer).species, where "unit" is a pointer to a vector of
> large (30 MByte) "unit" structures with multiple tags, one of which is
> a pointer to a vector of "layer" structures, and where each "layer"
> structure has "species" (a string) as one of its tags. Then commands
> of the form
>
> z = uniq ( (*(*unit[i]).layer).species, sort
> ( (*(*unit[i]).layer).species) ) , or
> subs = where ( (*(*unit[i]).layer).species eq 'PINE' )
>
> take much longer than with the original version (with the same
> elements in the vector).
>
> I have some work-arounds to recover some of the speed, but the
> question is what is really going on here, where minor changes in the
> code can cause large changes in the timing behavior of procedures that
> are outside the code that was changed? Is there some memory
> fragmentation issue? If so, how can this be overcome? (BTW, the
> memory footprint of the code with tables is actually 40% smaller than
> the original!) If anyone has any experience with something similar, I
> would really appreciate their insights here.
>
[Message index]
 
Read Message
Read Message
Read Message
Read Message
Previous Topic: Delaunay triangulation search
Next Topic: Re: Conversion floating point to byte or integer

-=] Back to Top [=-
[ Syndicate this forum (XML) ] [ RSS ] [ PDF ]

Current Time: Thu Oct 09 19:30:44 PDT 2025

Total time taken to generate the page: 0.80326 seconds