"clipka" <nomail@nomail> wrote:
> nemesis <nam### [at] gmailcom> wrote:
> > Quite frankly, hardly any external general-purpose language would do
> > much better at pure speed than using this method.  They'll still have to
> > parse and create the objects in the same manner, by binding some of its
> > particular calls to calls to povray object-creating functions and
> > methods.  But there's also a compilation step.  And I don't believe
> > parsing itself would be faster by going with a general purpose language,
> > even lightweight ones like Lua, Tcl or Scheme.
>
> There is a difference:
>
> Bytecode is more compact. It doesn't have whitespace, nor comments. It doesn't
> refer to variables or keywords (commands in bytecode) by names, but by indices
> in a table instead. Its command block ends are already identified. Its code -
> and moreover that of include files - is executed from memory instead of a
> (hopefully buffered) disk access module.
>
> So...
>
> - Disk access is reduced to the absolute minimum, not only because the files are
> likely smaller, but also because macro calls don't cause re-opening of the files
> they're declared in.
>
> - No need to seek over whitespace and comments.
>
> - No need to seek the end of a token.
>
> - No need to re-compute the hash of a variable name each time it is encountered.
>
> - No need to seek the end of an else-block.
>
> - No need to re-load code of macros executed.
>
> All this does not take up *much* time per statement - but if for instance you're
> calling the VRand macro in some loop a million times, then you *will* notice the
> difference.

I thought an SDL loop and its statements would be parsed only once and get
handled by an internal for loop.  Should've got more acquainted with pov's
source before trumpeting its amazing performance. :P

Very good answer and solid points, anyway.  Those are all indeed very solid
benefits of nicely performing interpreters, no doubt.  Thanks for correcting
me. ;)

Post a reply to this message