MattC
asked on
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
Mainly talking about useage of CString, CObArray, CInternetSession, CHTTPConnection, CFILE and CHTTPFILE
URL's, tips, personal thought all welcome
MattC
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
>>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
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
ASKER
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.
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.
>>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
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
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 :)
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 :)
ASKER
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.
:-)
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.
:-)
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
Paul
ASKER
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).
:-)
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).
:-)
hi MattC,
Do you have any additional questions? Do any comments need clarification?
-- Dan
Do you have any additional questions? Do any comments need clarification?
-- Dan
what about STL string, vector, fstream etc