POV-Ray : Newsgroups : povray.pov4.discussion.general : Caching parsed code : Re: Caching parsed code Server Time
1 May 2024 00:16:20 EDT (-0400)
  Re: Caching parsed code  
From: clipka
Date: 15 Apr 2009 17:50:01
Message: <web.49e6553be0976a9b255d1edc0@news.povray.org>
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'm not against a better, more expressive SDL that would allow for far
> better and convenient scripting and do away with many name clashes with
> true scoping rules.  Just pointing out that that kind of power may also
> mean slower rather than higher performance.

It will possibly be slower indeed for scripts that execute comparatively fast
and make not much use of include files. But it will sure make a difference for
those scenes that currently take half an hour of parsing, whiling away in some
loop forcing that VRand macro to be re-loaded and re-parsed for the gazillionth
time, character by character.


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.