A case where conventional wisdom may not apply
in [C++]
|
From: Peter Olcott on 17 Jun 2010 03:54 Conventional wisdom says to get the code working and then profile it and then make those parts that are too slow faster. What if the original goal is to make the code in the ball park of as fast as possible? For example how fast is fast enough for a compiler? In the case of the time it takes for a compiler to compile, any reduction in time is a reduction of wasted time. *** NOTE *** Since we are only shooting for the ballpark of the fastest code, we only focus on those things that can have a big impact on speed. In other words the fastest basic design where the code is extremely readable. Readability is the first priority and speed is the secondary priority. I can see where this would take more time to get the code working. It also seems (from my many years of doing this) to result in high quality fast code in much less time than the conventional wisdom method. It results in high quality fast code in less steps than the conventional wisdom method because it is much faster to improve a design than it is to improve code. Design is at a much higher level of abstraction than code so there is much less to change. Because there is much less to change it takes much less time to improve a design than it does to improve code. *** NOTE *** All of the above only applies to the case where the original design goal is to make the code in the ballpark of as fast as possible. It may be as much as the majority of the time where the benefit of extra speed is not worth the additional development costs. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Bo Persson on 17 Jun 2010 07:40 Peter Olcott wrote: > Conventional wisdom says to get the code working and then profile > it and then make those parts that are too slow faster. > > What if the original goal is to make the code in the ball park of as > fast as possible? > > For example how fast is fast enough for a compiler? In the case of > the time it takes for a compiler to compile, any reduction in time > is a reduction of wasted time. > Yes, but you still have to find out where it spends most of its time. Is it disk I/O? Parsing the source? Symbol table management? Instantiating templates? Something els�? It doesn't help a bit if your parsing is lightning fast, if that just means the compiler has to wait longer for the next I/O operation to complete. Bo Persson -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Paul Bibbings on 17 Jun 2010 08:09 Peter Olcott <NoSpam(a)OCR4Screen.com> writes: > Conventional wisdom says to get the code working and then profile it > and then make those parts that are too slow faster. >From your beginning I would have supposed you to go on to discuss issues that relate to *execution* time. However... > What if the original goal is to make the code in the ball park of as > fast as possible? > > For example how fast is fast enough for a compiler? In the case of the > time it takes for a compiler to compile, any reduction in time is a > reduction of wasted time. .... you then bring in *build* time, and then ... > *** NOTE *** > Since we are only shooting for the ballpark of the fastest code, we > only focus on those things that can have a big impact on speed. In > other words the fastest basic design where the code is extremely > readable. Readability is the first priority and speed is the secondary > priority. > > I can see where this would take more time to get the code working. It > also seems (from my many years of doing this) to result in high > quality fast code in much less time than the conventional wisdom > method. .... we're suddenly talking about *development* time. I'm, then, left wondering which `time' it is that is important to you here. I mention my confusion because I would say that the issues involved in each case merit different considerations, and it is sometimes the case that one or more might have to be compromised in order to best promote the one or more that has the highest priority for a particular project. Regards Paul Bibbings -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Nick Hounsome on 17 Jun 2010 10:13 On 17 June, 19:54, Peter Olcott <NoS...(a)OCR4Screen.com> wrote: > Conventional wisdom says to get the code working and then profile it and > then make those parts that are too slow faster. > > What if the original goal is to make the code in the ball park of as > fast as possible? At what cost? > For example how fast is fast enough for a compiler? In the case of the > time it takes for a compiler to compile, any reduction in time is a > reduction of wasted time. > > *** NOTE *** > Since we are only shooting for the ballpark of the fastest code, we only > focus on those things that can have a big impact on speed. How do we know where the ballpark is? How do we know "those things" without profiling? If we're going to try to find them by analysis then how much time and money do we spend and how do we know that we've analyzed the the right things? > In other > words the fastest basic design where the code is extremely readable. > Readability is the first priority and speed is the secondary priority. If the code is extremely readable then most likely it is either not the fastest design or it is the design we would have come up with anyway without being hung up on performance. > I can see where this would take more time to get the code working. Why? If it is extremely readable then there should be few bugs. It might well take more time to DESIGN but that is the problem - How long do you spend looking for the fastest design (without profiling)? > It > also seems (from my many years of doing this) to result in high quality > fast code in much less time than the conventional wisdom method. > It results in high quality fast code in less steps than the conventional > wisdom method because it is much faster to improve a design than it is > to improve code. But it is much easier to analyse and test code than design. > Design is at a much higher level of abstraction than > code so there is much less to change. Because there is much less to > change it takes much less time to improve a design than it does to > improve code. > > *** NOTE *** All of the above only applies to the case where the > original design goal is to make the code in the ballpark of as fast as > possible. It may be as much as the majority of the time where the > benefit of extra speed is not worth the additional development costs. When has anyone EVER said to you "Make this as fast as possible and damn the cost and delivery date"? It's never happened to me in over 25 years. In the real world the first priority is the delivery date every time - even to the point that most places I've worked would rather send a customer a product that doesn't meet REAL performance requirements (not just "as fast as possible") than slip the delivery date. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Peter Olcott on 17 Jun 2010 10:15
On 6/17/2010 5:40 PM, Bo Persson wrote: > Peter Olcott wrote: >> Conventional wisdom says to get the code working and then profile >> it and then make those parts that are too slow faster. >> >> What if the original goal is to make the code in the ball park of as >> fast as possible? >> >> For example how fast is fast enough for a compiler? In the case of >> the time it takes for a compiler to compile, any reduction in time >> is a reduction of wasted time. >> > > Yes, but you still have to find out where it spends most of its time. > Is it disk I/O? Parsing the source? Symbol table management? > Instantiating templates? Something els�? > I just make sure that it does not spend much more time than necessary anywhere. > It doesn't help a bit if your parsing is lightning fast, if that just > means the compiler has to wait longer for the next I/O operation to > complete. > > > Bo Persson > > > -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |