All right, all right! Interim decision regarding qualified Object methods

[deadalnix]

On 12/07/2012 15:20, Michel Fortin wrote:
> On 2012-07-12 11:41:46 +0000, "bearophile" <bearophileHUGS at lycos.com> said:
>
>> Andrei Alexandrescu:
>>
>>> The issue is template code bloat. My impression from being in touch
>>> with the C++ community for a long time is that virtually nobody even
>>> talks about code bloat anymore. For whatever combination of industry
>>> and market forces, it's just not an issue anymore.
>>
>> There is no proof that template bloat won't be a problem in D (I
>> remember the first version of the D Objective-C bridge failing because
>> of code bloat, the second version seems to require changes in the D
>> language).
>
> I don't think templates were the culprit for the D/Objective-C bridge.
> Code bloat was, but that's something that was inherent to the design of
> the bridge. The bridge was using mixins extensively, and while I did
> everything I could to use regular non-mixin templates (because those can
> be reused when the template arguments are the same), it wasn't enough.
> In fact, given that all the wrapper functions written using mixins were
> virtual (so you could override them, which is quite a feature!) it meant
> they all needed to be instantiated even though they were not used anywhere.
>
> There's actually no way I could have reduced code bloat significantly
> even by writing all the code by hand in the most optimized way. Not
> unless I abandoned the capability to override functions, but that'd make
> the bridge almost useless.
>
> One thing that might have helped is if the linker could have striped all
> the classes that were not used in the final executable, something it
> couldn't do because all module info refers to them. But that wouldn't
> have helped with the compilation speed, which was becoming the second
> problem not far behind code bloat.
>
>
>> And it seems L1 code caches of CPUs aren't growing a lot (so I suggest
>> to not ignore having lot of code to swap in and out of those 32 kbytes).
>>
>> So maybe it will be useful to introduce in D some means to attack the
>> code bloat problem from several sides at the same time.
>>
>> Some time ago I have suggested one of such weapons, the @templated()
>> that allows to select what parts of a struct/class are templated
>> regarding to what template arguments (it's a refinement of an idea of
>> Stroustrup).
>>
>> Another weapon to attack the problem is introducing in the DMD
>> back-end an optimization (already present in LLVM, but I think not
>> used on default), merging of functions with the same body (leaving
>> just a jump as the body of the removed function, to keep their
>> function pointers distinct).
>
> Both desirable things, but I don't think those would have much impact on
> the D/Objective-C bridge.
>
>

I think this is not a problem as big as it is stated.

Most of that code will be executed close to never, and 60Mb isn't a big 
deal for any modern computer, not even for most cell phones now.