On Mon, 17 Aug 2009, Martin Bähr wrote:
> On Mon, Aug 17, 2009 at 04:22:57PM +0200, Henrik Grubbström wrote:
>>> Incidentally, is there any real size and/or speed advantage when
>>> using --without-portable-bytecode ?
>> Well, you do save on runtime data, since the bytecode tripples aren't kept
>> around after compilation.
>
> could you elaborate what that means?
In portable bytecode mode, the intermediate bytecode tripples are kept
around after compilation for more robust program dumping.
> non-portable bytecode is smaller?
Yes.
> making it less data to load at runtime?
Yes.
> making startup faster?
Possibly.
> does it provide any other advantages?
Non-portable bytecode is much less robust, since it contains addresses of
functions and constants in the pike runtime. It will thus run into
problems as soon as the runtime gets even a minor change. The problem
can manifest as anything, since function pointers are involved. You don't
want to know how hard it is to track down this kind of issue...
> like does it include generated machine-code?
Non-portable bytecode dumps the generated machine-code as is.
> does it run faster? (i doubt it)
Execution times are the same, since the same code is executed in the end.
> what are the advantages of portable bytecode?
The risk of decode_value() dumping core due to some minor runtime change
is reduced. Pike code dumped on one machine can be used on another (eg RPC).
I'd only recomend non-portable bytecode use in tightly controlled
environments (eg embedded controllers or similar).
> sure, it's portable, but who takes advantage of that feature?
Well, Roxen does...
> greetings, martin.
--
Henrik Grubbström <grubba[at]roxen.com>
Roxen Internet Software AB
|