Arrays will never ever be padded. Since they are allocated as malloc(sizeof(FOO)*elems).
I just checked with AIDO, the size grows about 40%, as could be expected, since there are some images and strings, but mostly mappings and arrays.
I know of no way to benchmark the speed of aido, though, but if you have booth large floats and integers it will probably be slower, since my CPU lacks native 64bit integers.
/ Per Hedbor ()
Previous text:
2003-09-19 06:44: Subject: Re: some results on number crunching
On Fri, Sep 19, 2003 at 04:55:01AM +0200, Martin Stjernholm, Roxen IS @ Pike developers forum wrote:
Aren't there? I see mostly yellow and green dots on http://pike.ida.liu.se/development/pikefarm/7.5.xml. NT has gotten
That's what I have:
---snip--- Compiling interpret.c interpret.c:2593: error: parse error before "if" interpret.c:43:1: unterminated #ifdef WARNING: Compiler failure! Trying without optimization! interpret.c:2593: error: parse error before "if" interpret.c:43:1: unterminated #ifdef ---snip---
At this point build fails (obviously). Just checked in. Will try to figure out what is wrong...
I'm not at all certain of that. It's primarily the memory consumption that's interesting to see in large apps like Caudium and Roxen.
They consume a lot by default anyway. Extra 10% will make no difference, I guess ;)
--with-double-precision and --with-long-long-int on most systems. Memory size for pure arrays goes up almost exactly 50%, which figures.
But at least not 100% :)
It also shows that svalues aren't padded to 16 bytes.
It depends on compiler flags. It might be padded (especially on Win32/MSVC).
Regards, /Al
/ Brevbäraren