Message-ID: <3AD0EB7D.9EA82A3F@jps.net> From: Dennis Yelle X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.os.msdos.djgpp Subject: Re: gdb still doesn't work for me References: <3AD0B992 DOT 44D0D3C3 AT jps DOT net> <4634-Sun08Apr2001234906+0300-eliz AT is DOT elta DOT co DOT il> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 110 Date: Sun, 08 Apr 2001 15:51:41 -0700 NNTP-Posting-Host: 216.119.27.251 X-Complaints-To: abuse AT onemain DOT com X-Trace: nntp1.onemain.com 986770062 216.119.27.251 (Sun, 08 Apr 2001 18:47:42 EDT) NNTP-Posting-Date: Sun, 08 Apr 2001 18:47:42 EDT To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com Eli Zaretskii wrote: > > > From: Dennis Yelle > > Newsgroups: comp.os.msdos.djgpp > > Date: Sun, 08 Apr 2001 12:18:42 -0700 > > > > I ran the program, like this: > > test > z > > It finished in less than 1 second. > > > > I ran gdb like this: > > gdb test.exe > > break main run > > n > > n > > n > > n > > n > > n > > n > > At this point, the program produces about 64 lines of > > output to the screen, but I noticed a significant pause > > every 4th line. > > The total of all of the pauses was far more than 1 second. > > So, it seems to me that the program is running significantly slower > > under gdb than when run alone. > > No, GDB doesn't slow down programs, unless the program does something > very special, such as issues a lot of DPMI function calls, or > generates lots of SIGFPE exceptions. > > Normal programs don't do that. But your program, especially its car5 > function, allocates lots of memory in very small chunks (because it > creates lots of temporary Bset objects), which forces the library to > requests lots of small allocations from the DPMI server. Each such > allocation gets caught by GDB, because it needs to be aware of all > memory allocated by the program being debugged, to be able to > deallocate that memory if the program is restarted without exiting the > debugger. This causes a huge overhead, which is why you see this > terrible slowdown. Thank you very much for taking a look at this problem. I modified the program to print only 18 lines, and to call car6() instead of car5(). car6 is now this: ------------------------------------- void car6() { int count = 0; for( int i=0; i<10; i++) { cout << "car6, i=" << i << '\n'; unsigned long ii = i; for( int j=0; j<100; j++) { unsigned long jj = j | ii; for( int k=0; k<100; k++) { unsigned long kk = jj | k; for( int m=0; m<100; m++) { unsigned long mm = kk | m; if ( mm == 127) if ( ++count < 5) cout << "car6: " << ((i*100+j)*100+k)*100+m << '\n'; } } } } } -------------------------------------- As you can see, the only memory allocation is a few ints and a few unsigned longs on the stack, and possibly in the calls to cout, but there are only 14 of those. I don't think that gdb should be intercepting these more than once, do you? There terrible slow down is still there, in car6, which takes much more than 10 times as long to run under gdb as when run directly from the command line. The new file is at http://www2.jps.net/~vert/test6.cpp the input file is still at http://www2.jps.net/~vert/in and it still takes less than 1 second to run from the command line like this: test and much more than 20 times as long to run this way gdb test.exe break main run n n n n n n Thanks to anyone who reproduces this problem or figures out exactly what is going on here and how to fix it. Dennis Yelle -- I am a computer programmer and I am looking for a job. There is a link to my resume here: http://table.jps.net/~vert/