[Pharo-project] [Vm-dev] Re: Can OSProcess functionality be
implemented using FFI instead of plugin?
dionisiydk at gmail.com
Sat Jan 23 15:30:28 UTC 2016
2016-01-22 22:35 GMT+01:00 Eliot Miranda <eliot.miranda at gmail.com>:
> Let's measure this. Let's say we have 8 platforms (that's an
> underestimate, because different Linux distributions may have different
> values for certain constants), but 8, which is 4 basic platforms times 32-
> & 64-bits. We have Mac x86 32-bit, Mac x64 64-bit, Windows x86
> 32-bit, Windows x64 64-bit, Linux x86 32-bit, Linux ARM 32-bit, Linux x64
> 64-bit, and soon enough there will be more. Further, there may be
> different versions over time.
> So each of those initialization methods has
> - 1 slot for the global variable to be assigned
> - 1 slot for the literal value to assign to it
> - 3 bytes of bytecode per initialization for small methods, 4 for large
> methods. Let's say 4.
> So the overhead in 32-bits is 12 bytes per constant, and in 64-bits is 20
> bytes. So the overhead per constant for all platforms is 96 bytes per
> constant in 32-bits and 160 bytes per constant for 64-bits. A full system
> with sockets, files, a database connexion etc could easily exceed 100
> constants. I think it would be nearer 1000. So the overheads are in the
> 10- to 100-k byte range (100k ~= 0.5% of the image) on 32-bits. That's low
> but it's also pure overhead. Every GC has to visit them. Every senders
> and implementors has to visit them, but they offer nothing of value.
> Whereas the small parser for whatever notation is used to store the
> constants externally (if they are needed in a given deployment) has a small
> constant overhead; its simple code.
> Further, you still need the machinery to export the constants to be able
> to generate these initialization methods. If you've got the machinery and
> you don't need the methods why bother to generate the methods?
> As the Scots say, many a mickle makes a muckle.
Thank's Eliot for such detailed explanation. It makes sense.
But personally I prefer Smalltalk solution although Smalltalk itself is
pure overhead comparing to C.
My question was raised by Mariano idea to save ston files in methods. I
think it can reduce problems which you described.
But then literal array syntax can be more suitable than ston.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Vm-dev