code optimization was: Trivia: Processor MHz

Hello Walden ( and Phillip and others interested in the subject as I am ),

In this day of very cheap, practically free, cpu, I think the readability
and logical organization of code is much more important than the nbr of
instructions needed to run to perform a function. I think that even code
bloat gets a bad rap.  If the bloat is organized and it runs fast on a human
scale ( sub second ), then it is not bloat.

More times than not, optimizing code reduces its readability.  If what you
are optimizing is already sub second, you are being counterproductive.  Only
on the cpu challenged as400 does activity like this have a justification.

Steve Richter


----- Original Message -----
From: "Walden H. Leverich" <WaldenL@TechSoftInc.com>
To: <midrange-l@midrange.com>
Sent: Friday, December 28, 2001 2:18 PM
Subject: RE: Trivia: Processor MHz


> Steve,
>
> I'm not sure it's bloat free. How about taking away the strcpy line and
> simply assigning the pointer in the new string to the pointer in the old
> string. I know they would both point to the same memory location, but you
> wouldn't have to worry about that until it was actually time to change one
> of the strings. Only at that point you would make a copy. I'll bet you'd
> find you saved yourself a good number of strcpys by doing that.
>
> -Walden
>
> ------------
> Walden H Leverich III
> President
> Tech Software
> (516)627-3800 x11
> WaldenL@TechSoftInc.com
> http://www.TechSoftInc.com
>
>
>
> -----Original Message-----
> From: srichter [mailto:srichter@mail.autocoder.com]
> Sent: Friday, December 28, 2001 02:02
> To: midrange-l@midrange.com
> Subject: Re: Trivia: Processor MHz
>
>
> >From: Chris Rehm <javadisciple@earthlink.net>
>
> >>
> >The provider of the standard libraries so that the method linked in is
> >the MI accessing method.
> >
> >But again that is a complaint about the compiler. There is no
> >requirement that there be some inefficient string processing. Nor is
> >there a requirement that only RPG get to use MIs when they suit a
> >purpose.
> >
> >My contention is that it is not a requirement of "modern programming
> >languages" that they be able to burn extra processing cycles. That is a
> >requirement of less than optimum compilers and poorly coded standard
> >libraries.
> >
>
> Chris,
>
> Here is a c++ string class:
>
> Class String {
>
> // two data mbrs. lgth of the string and
> // a ptr to string data.
>   int mnLgth ;
>   char* mpData ;
>
> // an assignment member function.
> // user of the class codes as: string1 = string2
> // ( some confusing symbols left out )
> String operator=( const String string2 ) ;
> } ;
>
> // here is the assignment mbr function code.
> String String::operator=( const string2 )
> {
> if ( mpData != NULL )
>   {
>   free( mpData ) ;  // free old string
>   }
>
> // allocate string memory.
>   mnLgth = string2.GetLgth( ) ;
>   mpData = malloc( mnLgth + 1 ) ;
>
> // store the string value.
>   strcpy( mpData, string2.GetBuffer( ) ) ;
>
>   return *this ;
> }
>
> The string class is then used in a pgm:
>   String sEvilDoer ;
>   sEvilDoer = "Ibm leadership" ;
>
> This code takes a lot of cpu to run, is bloat free, abstracts away a bunch
> of details the pgmr does not need to have deal with, does not give much
> chance to optimize and would make our as400 grind to a halt if run as
> frequently as efficient RPG pgms are run.
>
> Steve Richter
>
>
> _______________________________________________
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
> To post a message email: MIDRANGE-L@midrange.com To subscribe,
unsubscribe,
> or change list options,
> visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
> or email: MIDRANGE-L-request@midrange.com
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.
> _______________________________________________
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
> To post a message email: MIDRANGE-L@midrange.com
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
> or email: MIDRANGE-L-request@midrange.com
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.
>
>