× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Actually, my idea wasn't original I stole it from the Microsoft
implementation of strings in MFC. I don't remember exactly what the numbers
were, but I know they saw significant performance increases when they made
that change. Remember, the damn copy constructor can get called all over the
place with hidden objects getting created all the time.

-Walden

------------
Walden H Leverich III
President
Tech Software
(516)627-3800 x11
WaldenL@TechSoftInc.com
http://www.TechSoftInc.com



-----Original Message-----
From: Steve Richter [mailto:srichter@AutoCoder.com]
Sent: Friday, December 28, 2001 14:39
To: midrange-l@midrange.com
Subject: 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.
>
>

_______________________________________________
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.


As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.