DWT+OpenGL crashing on Vista [OT]

John Reimer terminal.node at gmail.com
Sun Jan 18 18:28:51 PST 2009


Hello Jarrett,

> On Sun, Jan 18, 2009 at 7:41 PM, Bill Baxter <wbaxter at gmail.com>
> wrote:
> 
>>> Off topic - I wonder why executable could be so big? (Forgive my
>>> ignorance I am not either Tango/DWT/Derelict user)
>>> 
>> I dunno, but it's a frequent complaint.  Maybe the linker just isn't
>> very good at throwing away unneeded code?
>> 
> It isn't, from what I understand.  Also, anything declared as a
> "const" is never thrown away and takes up space in the executable.
> Also struct and class inits, and typeinfo.  It adds up.
> 


Yes, Dwt has a long list of 'const' declarations in it.  Feeling this was 
a serious concern, I once endeavored to convert as many as possible to enum 
(but never completed the task).  Anyway, even with many many const's taking 
up space, it doesn't appear to account for the large binary size of an executable. 
 If there were several thousand 'const' declarations, how would that account 
for more than a 10+ KB of storage?  I wasn't able to justify that at least 
by my own understanding.


What has been discussed before is the number of modules that get imported. 
 There is a a near 1 to 1 ratio for class per modules, and dwt has so many 
classes; I think this adds an extraordinary amount of module typeinfo to 
the linker, some of which may be redundant or just sitting around taking 
up space.   Furthermore,  dwt does not attempt loose coupling of classes 
by any stretch of the imagination.  So most modules need a reference from 
another module for significant or insignificant reasons.  This means a typical 
application pulls in most of the modules in the whole dwt tree.


I don't know the nitty gritty details of the problem, but I've heard that 
a re-engineered linker might do the trick.


For one thing, we do need a simple way to implement a dynamic library version 
of it.  A ddl version was demonstrated as feasible, but it really was not 
as simple as I'd like for the end-user.   I was thinkng of another possible 
solution that would mean a slight refactoring of the public classes such 
that they would be converted to interfaces and then linked to a dynamic library 
containing the original classes.  But the task might be too significant a 
change to dwt to warrant the fix.  I'm still thinking it over, though.


-JJR





More information about the Digitalmars-d mailing list