<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>Hi Denis,</div><div><br>On Jan 23, 2016, at 7:30 AM, Denis Kudriashov &lt;<a href="mailto:dionisiydk@gmail.com">dionisiydk@gmail.com</a>&gt; wrote:<br><br></div><blockquote type="cite"><div><span></span></div></blockquote><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">2016-01-22 22:35 GMT+01:00 Eliot Miranda <span dir="ltr">&lt;<a href="mailto:eliot.miranda@gmail.com" target="_blank">eliot.miranda@gmail.com</a>&gt;</span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="gmail_quote"><div>Let's measure this.&nbsp; 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- &amp; 64-bits.&nbsp; We have Mac x86 32-bit, Mac x64 64-bit, Windows x86 32-bit,&nbsp;Windows&nbsp;x64 64-bit, Linux x86 32-bit,&nbsp;Linux ARM 32-bit, Linux x64 64-bit, and soon enough there will be more.&nbsp; Further, there may be different versions over time.</div><div><br></div><div>So each of those initialization methods has</div><div>- 1 slot for the global variable to be assigned</div><div>- 1 slot for the literal value to assign to it</div><div>- 3 bytes of bytecode per initialization for small methods, 4 for large methods.&nbsp; Let's say 4.</div><div><br></div><div>So the overhead in 32-bits is 12 bytes per constant, and in 64-bits is 20 bytes.&nbsp; So the overhead per constant for all platforms is 96 bytes per constant in 32-bits and 160 bytes per constant for 64-bits.&nbsp; A full system with sockets, files, a database connexion etc could easily exceed 100 constants.&nbsp; I think it would be nearer 1000.&nbsp; So the overheads are in the 10- to 100-k byte range (100k ~= 0.5% of the image) on 32-bits.&nbsp; That's low but it's also pure overhead.&nbsp; Every GC has to visit them.&nbsp; Every senders and implementors has to visit them, but they offer nothing of value.&nbsp; 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.</div><div><br></div><div>Further, you still need the machinery to export the constants to be able to generate these initialization methods.&nbsp; If you've got the machinery and you don't need the methods why bother to generate the methods?</div></div><div class="gmail_extra"><br></div>As the Scots say, many a mickle makes a muckle.</blockquote></div><br>Thank's Eliot for such detailed explanation. It makes sense.&nbsp;</div><div class="gmail_extra">But personally I prefer Smalltalk solution although Smalltalk itself is pure overhead comparing to C.</div></div></div></blockquote><div><br></div>I can see the draw of the pure Smalltalk. Simplicity and brows ability. &nbsp;But imagine a tiny headless image deployed on containers, say 2mb. &nbsp;Now 100kb of initialization code doesn't look so good :-). &nbsp;Anyway I'm beating a dead horse. &nbsp;Mariano is generating initialization methods.<div><br></div><div><br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra">My question was raised by Mariano idea to save ston files in methods. I think it can reduce problems which you described.</div><div class="gmail_extra">But then literal array syntax can be more suitable than ston.&nbsp;</div></div>
</blockquote><div><br></div>I just want to be clear, I'm neutral about the notation used to export info from the C file. &nbsp;Liberal array syntax, chunk source format, ston, xml. &nbsp;It doesn't matter as long as it's convenient at expressing an attribute dictionary from names to attributes such as value, size, offset. &nbsp;Don't get hung up on the specific notation. &nbsp;If one were to go with the external file the only real requirements are that it be reasonably compact and quick to parse. &nbsp;That might kill xml but leave plenty of other candidates.<br><div><span style="background-color: rgba(255, 255, 255, 0);"><br><br>_,,,^..^,,,_ (phone)</span></div></div></body></html>