VBA performance

  • Thread starter Thread starter Carrie
  • Start date Start date
C

Carrie

How does an .mde file compare to a normal .mdb file in
terms of execution speed?

And is the code compiled into a form of executable file or
is it compiled over and over again at runtime?
 
IMHO - once code is compiled in MDB - its getting the same code as in MDE,
until you change any module
should not be any advantage, except that mde file size in bit smaller
 
Carrie said:
How does an .mde file compare to a normal .mdb file in
terms of execution speed?

And is the code compiled into a form of executable file or
is it compiled over and over again at runtime?


Exection speed is nearly the same, but an mde may load a
little (probably not noticable) faster.

The code must have been compiled as part of the process of
creating an mde. A key thing about mde is that the VBA
source code has been discarded, the mde is still essentially
the same as a compiled mdb (without the VBA source) and
still requires Access or Accress Runtime to execute it.

Note, if you should make an mde, be sure to keep a copy of
the original mdb for making future changes because there is
no way to make additional design changes to an mde.
 
And is the code compiled into a form of executable file or
is it compiled over and over again at runtime?

No, it is not compiled...but if you have a mdb, then often code or certain
things can cause it to be un-compiled..and that can really slow things down.
However, as a normal operation, the code after compiled does stay in that
state.

And, to further this, VBA actually gets compiled down to p-code, and not
native Intel assembler code like c++, or even VB6.

However, for reading data from JET, or sql server, there is generally
little, or no difference in performance if you use c++, VB6, or ms-access.
Ms-access VBA can easily execute 30 to 100 million instructions per second
on a average computer. This just means that Processing on a average computer
to day is not the problem..and increasing processing with do very little to
help ms-access performance. The real issue, or enemy to day in terms of
performance is not processing..but bandwidth..and how fast the data can be
feed to your application (it spends most of its time waiting).

So, processing power is generally a non issue with ms-access on late model
PC.
 
Back
Top