|
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 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.
midrange.com
