Vb6: P-Code is smaller, faster and more stable!?

Ralph

2006-08-23 18:12:56 UTC

Post by Christoph Guentner
Hello,
I use Visual Basic 6 to create my application.
P-code ist smaller than native code. I think that is clear.
But I have always read (and though thought) that native code is faster and
better.
When I compile my application to P-code it runs faster than when compiled to
native code,
e.g. one routine takes around 20 ms in P Code, but in native code almost one
second!
All in all in P-Code the application runs double fast as in native code.
It seems that P Code is much faster with objects.
Native code seems only to be a bit faster on arithmetic code.
And I have had some weired crashes when compiling to native code, e.g. the
exe crashed when returning from a subroutine on 'End Sub'! In the IDE there
was no crash.
And I "fixed" some other crash by just moving some declaration some lines up
or down!
I have not yet had such crashes with P-ode or in the IDE
So, it seems that P code is smaller, faster and more robust.
But in the documents and in the web always native code is recommended. Why?
What is the disadvantage of P-Code?
Chris

This subject has been beaten to death many times. If you do a Google search
on newsgroups, you will find more information on this that you likely ever
wanted to know. <g>

However, your observations are very correct. If an app is 'computational
intensive' it will run faster if compiled to native code, otherwise pcode is
faster. You are also correct that you will find various authors proclaiming
a definite superority of one over the other - more often than not it their
opinion is based mostly on personal preference, or a specific situation,
than on any real technical merit.

Which is best, depends entirely on your problem domain, how you like to
develop, and YOUR comfort zone. Like all programming decisions it is a
simple matter of trade-offs. One man's horror is another's nirvana.

Some examples:
PCode makes it a bit easier for someone (who knows what they are doing) to
steal your intellectual property compared to native code. This is likely
less an issue for in-house apps than it is for shrink-wrap. Decompiling any
VB app is never a trivial exercise, but some are just more comfortable with
native code.

Native code is easier to debug using WinDbg or other tools, opposed to
having only VB as a debugging tool. Again depending on your environment and
skill-level this is likely to be a non-issue.

As for the "crashes". That is a bit worrisome. There are documented cases of
some code that when compiled to native code will break. But they tend to be
exotic, obscure, rather contrived conditions, and are seldom encountered in
the real world.

Of course, with out seeing the actual code it is impossible to say for sure,
but I suspect that the problems you are running into are the result of buggy
code. There is a certain amount of 'forgiveness' built into pcode. It tends
to perform more validation and coercion on parameters, for example. But
'curing' the problem by moving declarations around suggests that something
is wrong with the stack, and you are only hidding a problem temporarily.

Whether or not "Forgiveness" equals "Robustness" depends on your comfort
zone. <g>

hth
-ralph