From: Daniel T. on
"Leigh Johnston" <leigh(a)i42.co.uk> wrote:
> "Daniel T." <daniel_t(a)earthlink.net> wrote:
> > "Leigh Johnston" <leigh(a)i42.co.uk> wrote:
> > > "Daniel T." <daniel_t(a)earthlink.net> wrote:
> > > > "Leigh Johnston" <leigh(a)i42.co.uk> wrote:
> > > > > "Daniel T." <daniel_t(a)earthlink.net> wrote:
> > > > >
> > > > > > CodePoint and UTF32[N] are two representations that both
> > > > > > refer to the same piece of knowledge. Why the unnecessary
> > > > > > duplication?
> > > > >
> > > > > It is not unnecessary *if* there is a noticeable performance
> > > > > improvement. I agree however that premature optimization
> > > > > should be avoided (obviously) which is why profiling should be
> > > > > performed
> > > >
> > > > I'm glad we agree that the code in question is probably an
> > > > unnecessary optimization.
> > >
> > > I didn't say that, it is unclear if the optimization is necessary
> > > and whether or not it is can be determined through profiling
> > > and/or examining the compiler's assembler output.
> >
> > Fine, but you do agree that it is an optimization, the only doubt
> > you hold here is whether or not it is necessary. Since no tests have
> > been presenting showing that code without the extra variable needs
> > optimizing, this is by definition, a premature optimization.
>
> No, using a temporary has no downsides (is at worst harmless) and yet
> could be beneficial from a performance standpoint which makes it (in
> my book) a win-win that doesn't deserve your criticism. I write such
> code quite a lot (use a temporary to avoid multiple dereferences),
> call me biased if you want.

I'm willing to agree that it's a style issue and as such, we have
already spent too much time discussing it. But your insistance that the
variable in question for this code example could possibly contribute a
measurable difference in performance in all but the most contrived
examples is ludicrous. To continue this discussion your going to have to
back up that claim with actual measurements. If on the other hand, you
keep insisting that it *might* contribute to performance, without
measuring, then you are admitting that adding the variable for that
reason is a premature optimization (by definition.) So which direction
do you want to take this? Is it is style issue, a premature
optimization, or do you have actual measurements?

"The problem with temps is that they are temporary and local. Because
they can be seen only in the context of the method in which they are
used, temps tend to encourage longer methods, because that's the only
way you can reach the temp." -- Marton Fowler.
From: Leigh Johnston on


"Daniel T." <daniel_t(a)earthlink.net> wrote in message
news:daniel_t-4A2939.07521301062010(a)70-3-168-216.pools.spcsdns.net...
> "Leigh Johnston" <leigh(a)i42.co.uk> wrote:
>> "Daniel T." <daniel_t(a)earthlink.net> wrote:
>> > "Leigh Johnston" <leigh(a)i42.co.uk> wrote:
>> > > "Daniel T." <daniel_t(a)earthlink.net> wrote:
>> > > > "Leigh Johnston" <leigh(a)i42.co.uk> wrote:
>> > > > > "Daniel T." <daniel_t(a)earthlink.net> wrote:
>> > > > >
>> > > > > > CodePoint and UTF32[N] are two representations that both
>> > > > > > refer to the same piece of knowledge. Why the unnecessary
>> > > > > > duplication?
>> > > > >
>> > > > > It is not unnecessary *if* there is a noticeable performance
>> > > > > improvement. I agree however that premature optimization
>> > > > > should be avoided (obviously) which is why profiling should be
>> > > > > performed
>> > > >
>> > > > I'm glad we agree that the code in question is probably an
>> > > > unnecessary optimization.
>> > >
>> > > I didn't say that, it is unclear if the optimization is necessary
>> > > and whether or not it is can be determined through profiling
>> > > and/or examining the compiler's assembler output.
>> >
>> > Fine, but you do agree that it is an optimization, the only doubt
>> > you hold here is whether or not it is necessary. Since no tests have
>> > been presenting showing that code without the extra variable needs
>> > optimizing, this is by definition, a premature optimization.
>>
>> No, using a temporary has no downsides (is at worst harmless) and yet
>> could be beneficial from a performance standpoint which makes it (in
>> my book) a win-win that doesn't deserve your criticism. I write such
>> code quite a lot (use a temporary to avoid multiple dereferences),
>> call me biased if you want.
>
> I'm willing to agree that it's a style issue and as such, we have
> already spent too much time discussing it. But your insistance that the
> variable in question for this code example could possibly contribute a
> measurable difference in performance in all but the most contrived
> examples is ludicrous. To continue this discussion your going to have to
> back up that claim with actual measurements. If on the other hand, you
> keep insisting that it *might* contribute to performance, without
> measuring, then you are admitting that adding the variable for that
> reason is a premature optimization (by definition.) So which direction
> do you want to take this? Is it is style issue, a premature
> optimization, or do you have actual measurements?

Yes it is both a style issue and a possible optimization. Even if it
doesn't contribute to a performance gain the fact the it contributes to good
style (IMO) still makes it desirable.

As far as timings are concerned for the OP function it *is* a premature
optimization if the input container is a vector (no performance gain,
optimizer doing its job) however if the input container is a deque the use
of a temporary gives a significant performance gain (twice as fast) as a
deque iterator/operator[] dereference is more complex than a vector's. Like
I said at worst using a temporary is harmless and at best it is improved
readability (IMO) and a possible performance gain which makes it a win-win
idiom. If this function was rewritten to take iterators rather than
containers then using a temporary would definitely be the best option as you
have no idea as to the complexity of an iterator dereference.

>
> "The problem with temps is that they are temporary and local. Because
> they can be seen only in the context of the method in which they are
> used, temps tend to encourage longer methods, because that's the only
> way you can reach the temp." -- Marton Fowler.

Obviously I disagree with this as IMO temporaries can improve the
readability of a function especially if they are given sensible names.

/Leigh

From: Christian Hackl on
Oliver Regenfelder ha scritto:

> This is not even a general C++ newsgroup but an MFC one.

The message was cross-posted to comp.lang.c++ and microsoft.public.vc.mfc.


--
Christian Hackl
hacki(a)sbox.tugraz.at

Milano 2008/2009 -- L'Italia chiam�, s�!
From: Peter Olcott on
On 5/31/2010 9:10 PM, Joseph M. Newcomer wrote:
> See below...
> On Mon, 31 May 2010 12:17:00 -0500, Peter Olcott<NoSpam(a)OCR4Screen.com> wrote:
>
>> I am not that concerned with performance. The number one priority is
>> readability and maintainability. Performance is secondary to this.
> ****
> But in all your previous posts, you were declaring that the real value of a DFA was that
> it was the fastest possible implementation. Suddenly, performance no longer matters.

No you merely screwed up yet again and misread what I said. You screw up
in this way quite often. This is your biggest single mistake. Your
second biggest mistake is gross over exaggeration.

As one example: You said that nothing can be known about the efficiency
of a method without testing. I have empirically proven this statement
completely false. I accurately predicted exactly how much another UTF8
decoder would be than my own code using the simple heuristic of
estimating the number of machine instructions in the execution path. 50%
more instructions did indeed result in 50% more time.

>
> And I still think the design is abysmal from a viewpoint of performance, usability,
> flexibility, and error reporting. Anyone who chooses to, in a general-purpose subroutine,
> pop up a MessageBox or do a printf, is simply clueless about how to design good software.
> ****

I already warned you that such statements are libelous and that you
should cease and desist such statements. No one else here had indicated
that the design is less than good.

>>> From the bits viewpoint, it is probably correct (I didn't work out all lthe shifts and
>>> masks, figuring you probably got those right) but from a design and architecture
>>> viewpoint, it is truly awful code given the stated goals. Besides limiting it to console
>>
>> That statement could be libelous. Cease and desist any such commentary.
> ****
> What statement? That it is awful code given the stated goals? That can't be libelous.

Do you really want to risk it?

>> It is by no means truly awful code, anyone that knows code well would
>> know this. Prospective future employers might not know code well enough,
>> and believe what you said.
> ****
> Sorry, I would not hire someone who was dumb enough to put a printf in a piece of code
> that could be used in a Windows environment, or even in a console environment.

Since no one else here thinks that my code is anything like abysmal that
shows that there is something else going on besides an objective
assessment of the quality of my code.
From: Leigh Johnston on


"Leigh Johnston" <leigh(a)i42.co.uk> wrote in message
news:sNKdnYeXgo04m5jRnZ2dnUVZ8mOdnZ2d(a)giganews.com...
>
>
> "Daniel T." <daniel_t(a)earthlink.net> wrote in message
> news:daniel_t-4A2939.07521301062010(a)70-3-168-216.pools.spcsdns.net...
>> "Leigh Johnston" <leigh(a)i42.co.uk> wrote:
>>> "Daniel T." <daniel_t(a)earthlink.net> wrote:
>>> > "Leigh Johnston" <leigh(a)i42.co.uk> wrote:
>>> > > "Daniel T." <daniel_t(a)earthlink.net> wrote:
>>> > > > "Leigh Johnston" <leigh(a)i42.co.uk> wrote:
>>> > > > > "Daniel T." <daniel_t(a)earthlink.net> wrote:
>>> > > > >
>>> > > > > > CodePoint and UTF32[N] are two representations that both
>>> > > > > > refer to the same piece of knowledge. Why the unnecessary
>>> > > > > > duplication?
>>> > > > >
>>> > > > > It is not unnecessary *if* there is a noticeable performance
>>> > > > > improvement. I agree however that premature optimization
>>> > > > > should be avoided (obviously) which is why profiling should be
>>> > > > > performed
>>> > > >
>>> > > > I'm glad we agree that the code in question is probably an
>>> > > > unnecessary optimization.
>>> > >
>>> > > I didn't say that, it is unclear if the optimization is necessary
>>> > > and whether or not it is can be determined through profiling
>>> > > and/or examining the compiler's assembler output.
>>> >
>>> > Fine, but you do agree that it is an optimization, the only doubt
>>> > you hold here is whether or not it is necessary. Since no tests have
>>> > been presenting showing that code without the extra variable needs
>>> > optimizing, this is by definition, a premature optimization.
>>>
>>> No, using a temporary has no downsides (is at worst harmless) and yet
>>> could be beneficial from a performance standpoint which makes it (in
>>> my book) a win-win that doesn't deserve your criticism. I write such
>>> code quite a lot (use a temporary to avoid multiple dereferences),
>>> call me biased if you want.
>>
>> I'm willing to agree that it's a style issue and as such, we have
>> already spent too much time discussing it. But your insistance that the
>> variable in question for this code example could possibly contribute a
>> measurable difference in performance in all but the most contrived
>> examples is ludicrous. To continue this discussion your going to have to
>> back up that claim with actual measurements. If on the other hand, you
>> keep insisting that it *might* contribute to performance, without
>> measuring, then you are admitting that adding the variable for that
>> reason is a premature optimization (by definition.) So which direction
>> do you want to take this? Is it is style issue, a premature
>> optimization, or do you have actual measurements?
>
> Yes it is both a style issue and a possible optimization. Even if it
> doesn't contribute to a performance gain the fact the it contributes to
> good style (IMO) still makes it desirable.
>
> As far as timings are concerned for the OP function it *is* a premature
> optimization if the input container is a vector (no performance gain,
> optimizer doing its job) however if the input container is a deque the use
> of a temporary gives a significant performance gain (twice as fast) as a
> deque iterator/operator[] dereference is more complex than a vector's.
> Like I said at worst using a temporary is harmless and at best it is
> improved readability (IMO) and a possible performance gain which makes it
> a win-win idiom. If this function was rewritten to take iterators rather
> than containers then using a temporary would definitely be the best option
> as you have no idea as to the complexity of an iterator dereference.
>
>>
>> "The problem with temps is that they are temporary and local. Because
>> they can be seen only in the context of the method in which they are
>> used, temps tend to encourage longer methods, because that's the only
>> way you can reach the temp." -- Marton Fowler.
>
> Obviously I disagree with this as IMO temporaries can improve the
> readability of a function especially if they are given sensible names.
>
> /Leigh

Additional:

On VC++ the use of secure (checked) iterators (which is the default) results
in the version which uses a temporary being at least twice as fast as the
version which uses iterators when the input container is a vector (like in
the OP). A combination of checked iterators and temporaries is both speedy
and safe, another win-win for the idiom.

/Leigh