• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 601
  • Last Modified:

MFC versus NON-MFC

I need some information regarding the performance hit incurred (if any) in using MFC classes as opposed to WIN32 API calls.

Mainly talking about useage of CString, CObArray, CInternetSession, CHTTPConnection, CFILE and CHTTPFILE

URL's, tips, personal thought all welcome

MattC
0
MattC
Asked:
MattC
  • 4
  • 3
  • 3
1 Solution
 
DanRollinsCommented:
The closest Win32 thing to a CString is a BSTR and the performance for that is dismal and it offers none of the convenience.  The closest Win32 API thing to CObArray is Safearray, and that is painful to use and I've read that its performance is also dismal.

CInternetSession and CHTTPConnection are thin wrappers for the WinInet API fns.  There is no detectable overhead for their use and they make life considerably easier (consider that all Internet access is invariably bandwidth-bound and never CPU-bound).  CHttpFile creates no overhead and simplifies web data access considerably.

CFile provides some significant convenience for file access.  Its 'drawback' is that it throws exceptions in some cases, rather simply returning an error code (as would the Win32 API calls that it wraps).  

If you go with straight Win32 API, you end up writing a bunch of support functions to match the functionality that is built into MFC.  Unless you are a multibillion-dollar firm with thousands of the world's best programmers, odds are, the support functions that you write will not be as efficient or bug-free as the ones that are already in MFC.

Now, for the things you didn't mention:  MFC provides great gobs of functionality for handling MDI and SDI applications and the framework upon which this functionality certainly incurs some processing overhead.  However, most of these this support is related to user interface, which is usually limited by how fast the user can type or click.  So even in a place where you can find some code corpulence, it is not a source of performance loss.

So, there you have it!  

-- Dan
0
 
makerpCommented:
>>CString is a BSTR

what about STL string, vector, fstream etc
0
 
DanRollinsCommented:
>>what about STL string, vector, fstream etc
If wdd STL objects to the question, then there are other alternatives.  If we add-in ATL constructs, or third party HTTP tools, then there are even more alternatives.  I was drawing the line, as suggested, at the Win32 API.

-- Dan
0
Get expert help—faster!

Need expert help—fast? Use the Help Bell for personalized assistance getting answers to your important questions.

 
MattCAuthor Commented:
Thanks Dan, Paul,

How about at run time, what penalties are incurred due to the use of the MFC's.  Difficult coding aside purely from a performance perspective.

0
 
DanRollinsCommented:
>>what penalties are incurred due to the use of the MFC's

Much of my post went to that point.  For most of the objects you mention, MFC provides a thin wrapper, with virtually no overhead.  In fact, many common member functions are implemented as inline Win32 calls.  So there is not even the overhead of 'calling a function that calls the Win32 API'.  In any case, such overhead is lost in the noise of the more relevant bottlenecks -- user input and hardware I/O.

The only proximate drawback is that the MFC DLL must be present on the system (it always is...) unless you use the static LIB version.  Using that will increase the size of your code and thus might incur some startup penalty.

Performance questions are best answered on a case-by-case basis.  Code a function with MFC, then code the same function without it.  Measure the time it takes to call each function 100,000 times.

Most performance bottlenecks are caused by poor algorithms.  Another cause is not understanding an MFC class.  Here is an example:  In an XML generator I wrote, I was using
      m_sXmlOut += sAddedOutput;
and when the XML string got to be around 100K long, my program started crapping out.  

The little '+' in that assignment statement involves locating the end of a 100KB string, and reallocating a new 101KB buffer, etc...  That takes a lot of time.  So I made a minor tweek to the code:  I actually append the output to a short (never > 5K) temporary string, and then occasionally append that data to the final string.  The result:  Output time went from over 30 seconds to under 1 second.  Now I *could* blame that on CString and thus run around saying that MFC sucks.  But the problem was not with CString, per se.  It was with how I was using CString.

-- Dan
0
 
makerpCommented:
if you actually look at the MFC code (it comes with vc++) you will see what dan means. it is a thin wrapper, if there are chunks of code around the win32 call they are usually nessecary and thus code you may end up writing yourself anyway!

i my opinion i would only use MFC for apps with a GUI interface. server code etc i use straight winsock, win32 calls STL etc. i think the real advantage to MFC resides in the GUI stuff. as i have already said, CString etc etc can be replaces with STL string etc which has a much richer set if methods and is no doubt faster, this probably goes for CObArray -> vector etc. also if you have used STL instead you will find porting your code to other platforms easier.

from the MFC classes you have suggested it looks like you are writing an internety type application.. if this is the case then write yout own HTTP class

if this is for a college/uni project code the HTTP yourself, it will go further to getting you good marks :)

0
 
MattCAuthor Commented:
Great guys, thanks, I had a look at the code andI understand what you mean now.

I think university lecturers may have tainted my initial view of MFC's, they seem to hate anything MS at my uni.

Thanks for the insight, I'll dish out some points soon.

:-)

0
 
makerpCommented:
i would use STL then, besides it is good and fast. writing a HTTP class good enough for a uni project aint hard, remember lectures will just want to see you have had a go and more importanatly understand the underlying protocol, if you use MFC then the protocol is all done for you.

Paul
0
 
MattCAuthor Commented:
well part of my project was to write a web crawler and store the hierarchy of a web site, so I concentrated on the multi-threaded aspect (thanks to Dan on that one as well I think :-)

This was just an idea on possible future improvements.  I originally thought that removing the use of MFC's might have a positive effect on performance, but I guess the benefit pails in comparison to the I/O block on HTTP request (only 2 at once to a web server) and then the subsequent download time.

But I would like to think that I could write code that would port to a couple of platforms, so maybe next time I'll do it all in ANSI C!!! (I can see me debgging memory leaks till I'm 50 with that one).

:-)
0
 
DanRollinsCommented:
hi MattC,
Do you have any additional questions?  Do any comments need clarification?

-- Dan
0

Featured Post

Get expert help—faster!

Need expert help—fast? Use the Help Bell for personalized assistance getting answers to your important questions.

  • 4
  • 3
  • 3
Tackle projects and never again get stuck behind a technical roadblock.
Join Now