On Sat, Nov 13, 2010 at 2:45 PM, Jeffrey Lee Hellrung, Jr. <jhellrung@ucla.edu> wrote> On 11/13/2010 10:39 AM, Daniel Walker wrote:
On Mon, Nov 8, 2010 at 7:24 PM, Domagoj Saric<dsaritz@gmail.com> wrote:
"Daniel Walker"<daniel.j.walker@gmail.com> wrote in message news:AANLkTin+bj=YeGtpo7sqLMUq2Nx3uG_teEFbcDMsM5Eb@mail.gmail.com...
On Tue, Nov 2, 2010 at 7:20 PM, Jeffrey Lee Hellrung, Jr. <jhellrung@ucla.edu> wrote:
Would it also be appropriate to measure the "space/call", in addition to "time/call" and "space/type"? Or is there no difference, or had this been addressed already?
Well, a call to boost::function does not cost any additional space.
How (or better, why) can you possibly claim something as plainly false as this..?
That this is false is obvious to anyone just following the discussion (and all the talk about the redundant if empty then throw logic/code) not to mention to someone that actually poked around the source code or even looked at the generated code....
boost::function allocates space when it is instantiated and assigned (e.g. line 580 of function_template.hpp), but not during a call to boost::function. Perhaps, you are referring to stack allocation? Yes, a call to boost::function could result in the stack growing, but that wasn't the question. If you are referring to the memory in the text section of the executable used to define operator() itself, yes, that's obvious, this is another space expense per type, but that wasn't the question. If you are aware of some other memory which is consumed during a call to boost::function, could you please be specific and include line numbers?
Actually, my original question was regarding space/call, with "space" referring to the same thing as your "space/type", i.e., space in the executable (in this case, the text segment). I believe I clarified this in a later post (no link handy). Sorry, I thought the context of the question made the terminology unambiguous.
OK, thanks for the clarification. The space per type in the text segment is now the only space overhead of the static empty scheme, since the static vtable assignment can be made const. So the size in the text segment is now the only important question. :) I re-ran the two benchmarks attached to the Trac ticket using gcc 4.2 and report the results below including text segment size. Function Benchmark Data (Release): | current | static empty time/call | 6.69e-09s | 6.26e-09s space/obj | 32B | 32B space/type (data)* | 32B | 32B space/type (text) | 6347B | 7386B Signal Benchmark Data (Release): | current | static empty time/call** | 1.55e-07s | 1.57e-07s space/obj | N/A | N/A space/type (data)* | 32B | 32B space/type (text) | 46539B | 47361B * Total size of the initialized static data section of the data segment, which shows that boost::function's contribution is 0B. ** On my machine these times are not consistent with every run. Sometimes the static empty scheme is up to 9% faster. So, you can see that the static empty scheme may or may not yield some time savings, but it does increase the total size of the text section by around 1000B in both tests. Again all of this is highly dependent on the compiler optimization and the specific circumstance in which it is used, which is why users should be given the choice as to whether or not to enable the static empty scheme. Daniel Walker