Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com X-Authenticated: #9087063 Message-ID: <429F0877.30805@gmx.de> Date: Thu, 02 Jun 2005 15:24:07 +0200 From: Axel Naumann User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) MIME-Version: 1.0 To: cygwin AT cygwin DOT com CC: Andy Ross , Vaclav Haisman , "Gerrit P. Haase" Subject: new vs malloc, -fno-exception - Re: Serious performance problems (malloc related?) Content-Type: multipart/mixed; boundary="------------010601010704030402030606" X-Antivirus: avast! (VPS 0522-9, 02.06.2005), Outbound message X-Antivirus-Status: Clean X-Y-GMX-Trusted: 0 --------------010601010704030402030606 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Hi, here's a little study, allocating / freeing mem in a loop, once with the C malloc/free, once (-DUSE_CXX_HEAP) using new/delete. It reproduces the factor ~3 for gcc cygwin. I've built it with MSVC's cl 7.0, gcc 3.3.3, with and without -mno-cygwin, using the cygwin-inst snapshot from 20050528, cygwin update from today, on a P4 1.8GHz, 512MB RAM, XPSP2 Prof. Result: the user fraction with "new" is 3 times the user fraction with "malloc". mingw and MSVC show no measurable difference.[1][2] cl -nologo : real 0m3.094s user 0m0.030s sys 0m0.016s g++ -mno-cygwin : real 0m3.733s user 0m0.031s sys 0m0.000s g++ : real 0m4.226s user 0m2.358s sys 0m1.796s cl -nologo -DUSE_CXX_HEAP: real 0m3.114s user 0m0.015s sys 0m0.015s g++ -mno-cygwin -DUSE_CXX_HEAP: real 0m3.811s user 0m0.015s sys 0m0.015s g++ -DUSE_CXX_HEAP: real 0m8.779s user 0m7.030s sys 0m1.671s To reproduce run make. NOTE: -fno-exceptions has no measurable impact on the results. Hope that helps, otherwise just ignore it (well - there no need to say that on cygwin-ml, I suppose :-) Axel. NB: the reason I care is because we see the same performance hit (since a few months) in the cygwin port of the _open_source_ program ROOT (root.cern.ch). [1]: The binary is run twice to make sure that the win cache is in the same state for all combinations. (Disabling the cache might be of academical interest. It's not real-world, real-use compatible, though.) [2]: The sys fraction is considerably higher (O(100)) for gcc compared with mingw/cl. I realize this is somewhat expected - but the amount is astonishing to me nevertheless. Anyway - that's for later. --------------010601010704030402030606 Content-Type: text/plain; name="check_cyg_mem.cxx" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="check_cyg_mem.cxx" #if USE_CXX_HEAP #include #define malloc(SIZE) new char[SIZE] #define free(POS) delete[] POS #else #include #endif int main(int argc, char* argv[]) { const size_t size=1000; const long int loop0=10; const long int loop1=100000; char *ptr[loop1]; int i0=0; int i1=0; for(;i0> $(OUTFILE) \ && bash -c "time ./check_cyg_mem.exe" >> $(OUTFILE) 2>&1 .phony: all builds run --------------010601010704030402030606 Content-Type: text/plain; charset=us-ascii -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ --------------010601010704030402030606--