Statically linked MFC applications are massive - by JoeWoodbury

Status : 

  Won't Fix<br /><br />
		Due to several factors the product team decided to focus its efforts on other items.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.


26
0
Sign in
to vote
ID 504714 Comments
Status Closed Workarounds
Type Bug Repros 17
Opened 10/27/2009 4:27:58 PM
Access Restriction Public

Description

I have a small native C++/MFC test console program that compiles to 278k with VC++ 6, 372k with VS 2008 and a whopping 1765k with VS 2010.
Sign in to post a comment.
Posted by Y Hamiaux on 10/18/2011 at 12:29 PM
I also try to reduce the size of our package. Is there a way in VC++10 to use MFC41... which is always present in Windows? When we statically link to mfc, the linker seem to add all code and data. When an application use a dialog box only, it's seem code for sliders, buttons... is also included?

Reading redist.txt, it's seem we could copy DLLs needed by our applications directly in the application folder? Hum, this sound really not clean to me...

Otherwise, I would suggest that if we can customize what goes inside vcredist___.exe and select the DLLs which are required and discard all other.
Posted by Ted_ on 4/16/2011 at 7:51 AM
static size fix for VS2008SP1+April12th security update:
http://tedwvc.wordpress.com/2011/04/16/static-mfc-code-bloat-problem-from-vc2010-is-now-in-vc2008-sp1security-fix/
Posted by Ted_ on 4/15/2011 at 8:50 PM
I can confirm, simple Appwizard generated MDI app without feature pack stuff (classic menu/classic toolbar) gives 553K release static EXE under SP1 and 1700K under SP1+April12th security update for VS 2008.
Posted by Violator73 on 4/14/2011 at 4:24 AM
It's getting worse:
With the latest Visual Studio security updates, we have the same problem now with VS2008. I suggest not to install those updates...
I do not believe any more that MS is willing to do something about this issue.
Posted by G_DEv on 3/30/2011 at 8:55 AM
This is a very important issue when developing for constrained platforms like winPe. I believe it should be addressed immediately.
Posted by David Delaune on 3/23/2011 at 2:46 PM
Visual C++ Libraries Development Team,

I simply cannot believe this issue was not addressed with VS2010 SP1. I have been developing with Visual C++ for over a decade and I can honestly say that beginning with the VS2010 I feel as if Microsoft is abandoning C++ developers. How is is possible to develop a library and not notice the binaries are 300% larger in some test cases.

What do I need to do to attract some attention to this issue? Is there anything I can do through the Microsoft Partner Network to get attention to this issue?

Posted by Violator73 on 12/20/2010 at 11:36 PM
@Microsoft:
Are there any plans to fix this issue with SP1? Currently we are using VS2010 with v90 toolset and we cannot switch to v100 until this problem is solved...
Posted by Koorlie on 11/25/2010 at 11:49 PM
It's quite amusing that someone actually suggested to use dynamic linking for this.

Many reasons why one would opt for static linking. But all of those escaped him.

We over here have an MFC app which no longer fits into the portable memory location where it used to be at...
Posted by MatrixDweller1 on 11/15/2010 at 2:27 PM
I noticed this today after upgrading to VS2010. My 2008 C++ exe with MFC statically linked was about 900Kb and now my 2010 C++ exe is about 2700Kb. I wouldn't be so concerned if it were merely a 10% or even 20% increase in size. 300% however is a little alarming. Like others have said, we use C++ so that we can make thing lean and mean.

The compiler will not include user created functions/classes not referenced (ie: /opt ref). Ideally it should also do this for anything else included in the project. I'm sure though that is quite a bit different when linking to a DLL.
Posted by KirkSquared on 11/12/2010 at 12:45 PM
The increase in executable size is just plain ridiculous and the workarounds available are rather undesirable. It makes zero sense to include code in the executable that is never used.

Granted, MFC was never intended to be a lightweight framework like ATL, but it used to be light enough to handle many small scale components.

Visual Studio 2010 has many improvements, but the help system and static linking of MFC are huge steps backwards.
Posted by charles_cotton on 10/27/2010 at 9:00 AM
I appreciate learning the true technical reasons for this huge increase is exe size from Pat Brenner. It takes the sting out a bit, until one realizes that, had the developers who implemented support for MFC controls in the Dialog Editor been paying attention to what their implementation was doing to the final exe size of static targets, they might have done things differently.

They obviously were not paying attention to this detail.

One wonders if they even realize how important it is to those who actually use MFC to keep the final exe file’s size as small as possible.

This has always been a cornerstone of MFC. If only the MFC developers had remembered this, the quality of the product would not have been compromised by such a bad implementation.

And no, Sheng Jiang, I have no interest in using the DLL build. That really would be jumping out of the frying pan into the fire!

You can do better!

Charles Cotton
Posted by David Ching on 8/17/2010 at 2:02 PM
@Sheng, what you suggest is not feasible. MFC100u.dll is 4.3 MB. The CRT shared DLL's (which must be bundled as well) combine to about 1.1 MB. Using shared DLLs totals 5.4 MB, which is a whole lot more waste than the ~1.5 MB minimum static link MFC app in VS2010.

@karx11erx, you have a point that 1.5 MB these days is not huge, at least compared to a decade ago when static link MFC ActiveX controls (min size 300 KB) was deemed too large, and thus ATL was born. Is 1.5 MB too much to ask in exchange for a ribbon designer? Yes, when with a little thought, it could have easily been reduced (see Ted's blog reference in Workarounds.) It just kind of shows that code craftsmanship isn't what it used to be at MS. But:

@Pat, thanks much for spending the time to look at this and report your findings. While I wish the developers had more of a "clean up after yourself as you go along, and not after the fact" attitude, it's helpful to us on the outside that you care enough to look at the problem at all.
Posted by Sheng Jiang 蒋晟 on 8/17/2010 at 1:21 PM
If size of static build is that much a concern you can use MFC as a shared dll.
Posted by werelord on 8/16/2010 at 2:37 PM
you don't know why 1.5 MB is a big deal?? Think scale..

Our application (1.8 MB with vs2k8) is used to build some 3000 downloads; before this change the footprint of our entire directory is 5.4 GB of data. If this change were to take place (3.2 MB with vs2010) that footprint would expand to 9.6 GB of data. To say this isn't a big deal is hogwash.

Size might not matter to you, but it does to a lot of people. There is a definite cost to size, both in storage, bandwidth amounts and the number of people successfully downloading the application; not everyone has fast broadband and there is a definite difference between 1.8 MB and 3.2 MB. Because you don't see the scale doesn't mean that this isn't a problem.
Posted by karx11erx on 1/29/2010 at 2:50 AM
joewoodbury,

I am not a Microsoft employee or affiliated with MS in any way other than as a customer, but I have to say the following:

As far as I can see it, you are complaining about a size increase of less than 1.5 MB. This looks rather ridiculous to me. Then you are complaining that you are building a console and not a dialog application, so the linker shouldn't pull any dialog code in. That makes me wonder why you are using MFC at all. Even if you should actually need MFC in your console application, I am wondering why having an extra 1.5 MB code is such a big deal, particularly given the explanation Pat Brenner has presented. Apparently the MFC coders assumed that if you are linking in MFC, you will be going to use at least some of its code and hence tried to make sure it will be able to provide all features it should. In that light your complaints and comments seem somewhat unreasonable to me.
Posted by Microsoft on 11/18/2009 at 4:59 PM
Joe,

We value your inputs. We have looked at many ways to reduce the resulting application in this scenario and the fix is too risky to take at this point of our product cycle.

This is definitely a good feedback for us. We will look into it in our future release.

Regards

Maya Widyasari
Windows C++ team
Posted by JoeWoodbury on 11/12/2009 at 12:53 PM
This isn't a dialog application, it's a console application that uses MFC.

And are you seriously saying that using an MFC dialog requires ribbon bar code to be used? If so, your design utterly stinks. I definitely won't be upgrading to VS 2010.
Posted by Microsoft on 11/12/2009 at 10:39 AM
Hi Joe,

I've spent most of the last couple of days investigating this, using verbose linker output to determine the dependencies that cause the addtional portions of MFC to be pulled in. The root cause is a new feature we added to MFC and the dialog editor.

The "MFC controls in the dialog editor" feature allows the user to put MFC controls on a dialog. He can then set properties on these controls that will affect the run-time behavior. This is done by adding data to the DLGINIT resource for the dialog in the RC file. MFC then gets the chance to parse the DLGINIT data when the dialog is initialized at run-time and at this point the parsing code (which resides in a central part of the MFC code) needs information about all the possible controls, so this pulls in a bunch of code. The control code needs to know how to draw the controls and this pulls in the visual manager code. The visual manager code needs more information about the control types it may need to draw so it pulls in even more code.

After investigating the current implementation, I have not found any possible fix. That's not to say that there isn't one, but any major fix at this point in the product cycle would be too risky. So we will investigate this further for a future release (really).

So that's the explanation for the size increase, and though the increase is not by design, the increased functionality that causes it is by design. I hope in this case I qualify as "anyone at Microsoft with any authority whatsoever" :-) but I'll let you be the judge.

Thanks again for the report and feedback, and for your help in the investigation of this issue.

Pat Brenner
Visual C++ Libraries Development


Posted by JoeWoodbury on 11/10/2009 at 3:51 PM
Start VS
Create a new project/solution
Select Win32
In the wizard, make sure MFC is selected

Once the project is created:

Change solution configuration to release mode
Open project properties
In General, change "Use of MFC" to "Use MFC in a Static Library"
In C/C++|Code Generation, change Runtime Library to "Multi-Threaded (/MT)"
Click OK
Build

(I also did the same steps using VS 2005 and VS 2008, closing the solution and reopening it in VS 2010)



Posted by Microsoft on 11/10/2009 at 3:29 PM
Hi Joe,

Can you tell me the steps you used to create the test application? I am looking into this to see if there is a simple fix, but I need either your project or your repro steps in order to narrow down where the extra stuff is being linked in. Thanks for any help.

Note that this is not "by design". And the fact is that I did not notice this--I am mostly working on the library itself and making sure that it is functional, and I confess that while I may have noticed the size increase of an application built with static MFC, I put this down to the increased capabilities and did not compare bare-bones applications to see if the size increase was there as well.

Pat Brenner
Visual C++ Libraries Development
Posted by JoeWoodbury on 10/29/2009 at 2:19 PM
Can anyone at Microsoft with any authority whatsoever explain how creating executables almost 8x larger than VS 2008 is by design? Please, I want to know the criteria you are using to get rid of obvious anomalies.
Posted by JoeWoodbury on 10/29/2009 at 2:17 PM
Size of simple console application created using the wizard and statically linked:

Visual Studio 2008 SP1 - 210,432
Visual Studio 2010 Beta 2 - 1,620,992
The 2008 solution converted to 2010 Beta 2 - 1,620,480

(Even if you use the /OPT:NOREF flag in the linker in VS2008, you only boost the size of the resulting executable to 541,696. A quick check of the map file from VS 2010 shows that it really is linking in just about everything.)
Posted by JoeWoodbury on 10/29/2009 at 1:50 PM
I am sure that you are aware that a well written library will only use that portion of its functionality that is required. If MFC is written such that 1.5MB must be linked for a simple static console application that means that for an application dynamically linking to MFC will be using the library in a very inefficient manner--you will see an increase of page faults among other things.

Unfortunately, you have a track record of saying you will look at improvements with you next product cycle, but you never do. You just make things bigger and slower and pretty much ignore all the complaints people have filed (and then act surprised when they are filed again.) Many of us have complained about the increased bloat of MFC and the CRT for years and its only gotten worse.

The bigger irony is that you are IN a product development cycle. If you have no intention of fixing anything but superficial bugs, why would you even have a beta program? What's the point?

The final point is how did you not notice this? I suspect you did and simply didn't care; an attitude that has permeated your C++ offerings outside the compiler and linker for years. You will no doubt protest that you do care, but you don't and its obvious to just about everyone in the developer community. Please wake up and look around for a change AND LISTEN. The entire point of using C++ is to create lean, fast applications. If I want bloat, I'll use .NET. YOU said "10 is the next 6", VC++ 6.0 was a lot more than just a class wizard, but that's all you see.
Posted by Microsoft on 10/29/2009 at 1:32 PM
Hello joewoodbury

Thanks for reporting this issue regarding the size of your statically linked MFC applications. As I am sure you are aware, the growing size of the MFC libraries is in part due to the functionality that has been added to MFC since VC6 - particularly recently with VS2008 SP1 and in VS2010. Unfortunately for VS2010, given our position in the product cycle, we will not be able to make the current behavior any different. We will be looking at compiler/libraries/linker improvements in our next product cycle, as we always do, and will investigate what can be done for future product cycles.

Thanks
Damien
Posted by Microsoft on 10/29/2009 at 2:19 AM
Thanks for your feedback.

We are rerouting this issue to the appropriate group within the Visual Studio Product Team for triage and resolution. These specialized experts will follow-up with your issue.

Thank you