digitalmars.D - Re: Compiler: Size of generated executable file
Roman Ivanov <isroman-rem move-km.ru> writes:
Walter Bright Wrote:I agree that a lot of the concerns are based on obsolete notions. First off, I just bought another terabyte drive for $90. The first hard drive I bought was $600 for 10Mb. A couple years earlier I used a 10Mb drive that cost $5000. If I look at what eats space on my lovely terabyte drive, it ain't executables. It's music and pictures. I'd be very surprised if I had a whole CD's worth of exe files. Next, even a very large executable doesn't necessarily run any slower than a small one. The reason is the magic of demand paged virtual memory. Executables are NOT loaded into memory before running. They are memory-mapped in. Only code that is actually executed is EVER loaded into memory.
I would say you're severely understating the issue. There are plenty of valid reasons why small executables are desirable. Imagine every Unix utility being several megabytes large. There are hundreds of them just in /usr/bin directory. The concerns about updating security problems and bandwidth usage are pretty rational as well. Besides, there is also an issue of marketing. People have a perception that larger programs run slower. Usually this perception is right. I would have hard time "selling" D programs as efficient to my boss, if the executables are much larger than their counterparts in other popular languages. Perhaps I'm missing something, but what would be involved in separating the stuff that bloats executables into a shared library?
Jan 13 2010
Walter Bright <newshound1 digitalmars.com> writes:
Roman Ivanov wrote:Perhaps I'm missing something, but what would be involved in separating the stuff that bloats executables into a shared library?
Creating a shared library version of Phobos requires someone to sit down and take the time to do it.
Jan 13 2010