Conversion from UTF32 to UTF8 for review
in [MFC]
|
From: Daniel T. on 1 Jun 2010 07:52 "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 1 Jun 2010 09:09 "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 1 Jun 2010 09:22 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 1 Jun 2010 09:38 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 1 Jun 2010 09:46
"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 |