Prev: Snapshot of screen
Next: Reading eg voltages from the USB port
From: Ralph on 2 Dec 2009 14:06

"Mike Williams" <gagamomo(a)yahoo.co.uk> wrote in message
news:a2872a02-8c23-4197-aa1a-720ef654eb31(a)d10g2000yqh.googlegroups.com...
> On 2 Dec, 04:35, "Ralph" <nt_consultin...(a)yahoo.com> wrote:
>
> > Pcode is one of those "dirty little secrets" - unless an
> > application is doing a lot of processing where the optimizing
> > compiler can help - most VB apps written will perform better
> > if compiled to pcode.
>
> I think I'd have to take issue with you on that one, Ralph. Although
> there are always exceptions, the general case is that native code is
> usually as fast as, and often very much faster than, pcode. It all
> depends on what your app is doing and on how much actual work is done
> "under the hood" in response to each line of your source code (whether
> a specific block of code is what I would personally call "top heavy"
> or "bottom heavy").
>
> There will be exceptions of course, but in general if you are
> performing blitting or other drawing functions or disk access or
> anything else of a "bottom heavy" nature then the performance of
> native code and pcode will generally be about the same, but if you are
> performing medium to "top heavy" stuff then native code is definitely
> faster. For example, when sorting an array of strings native code will
> only be about about 20 per cent faster than pcode, but if you are
> sorting an array of Singles or Longs, or otherwise working with such
> data, then native code is very much faster, typically about 500 per
> cent faster than pcode, and that's without any specific compiler
> optimizations.
>

Though I find it difficult to believe you actually get a 500x faster sort
without compiler optimization - I won't quibble. As I totally agree with
much of what you say.

With any performance issue one has to test. All the scenarios you described
are processes that can benefit from an optimizing compiler.

What I meant by "dirty little secret" was simply to point out that many
VBers compile to native code - taking it for granted that it will be
faster - when in fact the vast majority of VB programs are not doing any of
the processes you mentioned and can benefit from a pcode compile.

A simple click on an Options dialog is all it takes to find out.

-ralph


From: Ralph on 2 Dec 2009 17:02

"Gutless Umbrella Carrying Sissy" <taustinca(a)gmail.com> wrote in message
news:Xns9CD5873939337taustingmail(a)69.16.186.7...
> >> then native code is very much faster, typically about 500 per
> >> cent faster than pcode, and that's without any specific
> >> compiler optimizations.
> >>
> >
> > Though I find it difficult to believe you actually get a 500x
> > faster sort without compiler optimization - I won't quibble.
>
> Since he didn't say 500*x* faster, you shouldn't quibble. 500 *%*
> faster is 5*x* faster.
>

lol

Yeah, five 'times' faster seems a tad more probable - but still pretty darn
quick.

-ralph


From: Mike Williams on 2 Dec 2009 17:55
On 2 Dec, 22:02, "Ralph" <nt_consultin...(a)yahoo.com> wrote:
> "Gutless Umbrella Carrying Sissy" <tausti...(a)gmail.com> wrote in
> >
> > Since he didn't say 500*x* faster, you shouldn't quibble.
> > 500 *%* faster is 5*x* faster.
>
> lol
> Yeah, five 'times' faster seems a tad more probable - but
> still pretty darn quick.

Well it /is/ pretty darn quick. The "five times faster" that I quoted
for the specific kinds of code that I mentioned was just a ball park
figure of course, but I've since performed an actual test of sorting
an array of 50000 Singles using a standard ShellSort algorithm and the
timings are as follows (on this specific machine):

130 milliseconds PCode
59 milliseconds Native Code with all optimization turned off
25 milliseconds Native Code with standard default "Opt for fast code"
15 milliseconds Native Code with "Opt for fast" and "Remove Array
Bounds checks"

So, in this particular test native code is twice as fast as PCode with
no compiler optimizations whatsoever (not even the default "opt for
fast code), five times as fast as PCode with the standard "Opt for
fast code" optimization, and more than eight times as fast as PCode
with both "Opt for fast code" and "Remove array bounds checks"
optimization. So, my ball park figure of "five times as fast as PCode"
is not so far out when you consider that for these specific tests the
actual speed is between two and eight times as fast :-)

Mike






First  |  Prev  | 
Pages: 1 2
Prev: Snapshot of screen
Next: Reading eg voltages from the USB port