David Fontaine <dav### [at] faricynet> wrote:
: When POV parses, does it directly parse the text file? If so, perhaps it
: could load a compressed version into memory

  This is exactly what I have suggested some time ago. However, it's not
a simple task and I think the pov-team has more important things to do right
now :)

  Byte-compiled code will be faster to parse only when you have big loops
(I mean "big" in number of iterations), macros and so on. Reading a regular
file without them will only slow the parsing (because it has to first parse
it, as it does now, byte-compile it and then interpret that byte code).

  One advantage of byte-compiling is that you could save the binary data
to a file and then read it afterwards, saving the parsing and compilation
steps.
  A disadvantage of writing byte-coded binary data is that it's
system-specific and something written in one system may not work in another
system (because of different endianess, different floating point number
formats and so on). This, however, shouldn't matter when you are only
working for yourself. You can always give the source code in plain ascii
to others.

  By the way, as far as I know perl uses this tactique, that is, it first
parses the source script, byte-compiles it and then interprets this byte code.
This makes perl one of the fastest scripting languages in existence.
  And since perl "compiles" in the background, hidden from the user, the user
doesn't have to worry about the compilation step (as happens with java).
  But as I said, byte-compiling is beneficial only when there are loops and
other similar things in the code.

: I've stored integers between 0 and 10 in an array of doubles...

  Usually a bad idea :)
  (Well, for integer values between 0 and 10 it's ok, but don't use much
larger or smaller values... :) )

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message