in reply to Re: This runs WAY too slow
in thread This runs WAY too slow

Ok, so you've isolated a small piece of code that does something bad with some data, great work. But, you haven't given us a framework to test the code nor a failing data set, or even a real indication of what the input data should look like.

Although laziness is generally to be applauded in the Perl community, it's a form of laziness that requires some work up front. Just a little more work to put that code into a context we can run and a little data will go a long way toward saving us all some time in resolving your problem.

Note that with simulation bugs where you are using 'random' data it is often useful to seed the random number generator to ensure consistent results for debugging. Even for production code it is a good idea to record the seed that was used for a run so that unexpected results are easier to reproduce.

True laziness is hard work

Replies are listed 'Best First'.
Re^3: This runs WAY too slow
by Dandello (Monk) on Jan 17, 2011 at 06:36 UTC

    Sorry

    A test version is at Model 1

    It's supposed to have only two or three cells grayed out on row 5 and the the other two or three grayed out on 6 (for a total of five) with the grayed out cells extending down to the end of the table. Like this: Model 2 However, Model 2 doesn't use the 'while' statement and occasionally picks out a few too few to gray out.

      Of course, after posting this, I think I figured it out.

      if ( $dr4 < 0 ) { #pre-populate deletion array; my @delarray = ( 0 .. $chntot ); @dlarray = shuffle @delarray; my $cndiea = 0; foreach my $del ( 0 .. $chntot ) { if ( $aod[$del][$yb] eq 'd' ) { $cndiea++; } } my $cnr = $cndiea; for my $xd ( 0 .. $chntot ) { my $xda = $dlarray[$xd]; if ( $aod[$xda][$yb] eq 'a' && $cnr < $incrsdel ) { $aod[$xda][$yb] = 'd'; $cnr++; } } }
        Of course, after posting this, I think I figured it out.

        Around here that is considered a very good outcome and one of the reasons we like people to try to reproduce their problem with a small stand alone sample. Trying to isolate the problematic code very often results in an analysis of the code that otherwise is hard to achieve. In fact many monks who have been around here a while (myself included) find that the process of trying to generate a small stand alone script for posting in a SOPW gets the problem solved before the SOPW gets written.

        Please though, read ELiSHEVA's node carefully and follow as much of her advice as you can. She offers lots of very good advice that will help improve you code to make it faster and more maintainable.

        True laziness is hard work