digitalmars.D - this was never answered...
- Regan Heath <regan netwin.co.nz> Jun 20 2004
- "Walter" <newshound digitalmars.com> Jun 20 2004
- Regan Heath <regan netwin.co.nz> Jun 21 2004
- J C Calvarese <jcc7 cox.net> Jun 21 2004
- Ivan Senji <ivan.senji public.srce.hr> Jun 21 2004
- Regan Heath <regan netwin.co.nz> Jun 21 2004
- "Walter" <newshound digitalmars.com> Jun 21 2004
- Regan Heath <regan netwin.co.nz> Jun 21 2004
- "Walter" <newshound digitalmars.com> Jun 22 2004
- Regan Heath <regan netwin.co.nz> Jun 22 2004
When I compile tiger (the crypto algorithm) with a main fn that simply prints DONE and exits, then run it, it runs, uses 1MB memory, prints DONE, then keeps running for another 90 seconds, uses another 14MB of memory, before returning to the command prompt. What is it doing? This only happens in a debug build. My compile/link options are: d:\D\dmd\bin\dmd.exe -c "$(InputPath)" -g -gt -debug -unittest -od"$(IntDir)" d:\D\dmd\bin\dmd.exe -g "$(IntDir)\*.obj" -of"$(OutDir)\$(WkspName).exe" Im using MSDEV the $() above are replaced by the file names involved. Regan. -- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Jun 20 2004
I don't know what it's doing. Perhaps putting some strategic printf's will help pin down where it's spending the time. "Regan Heath" <regan netwin.co.nz> wrote in message news:opr9w96man5a2sq9 digitalmars.com...When I compile tiger (the crypto algorithm) with a main fn that simply prints DONE and exits, then run it, it runs, uses 1MB memory, prints DONE, then keeps running for another 90 seconds, uses another 14MB of memory, before returning to the command prompt. What is it doing? This only happens in a debug build. My compile/link options are: d:\D\dmd\bin\dmd.exe -c "$(InputPath)" -g -gt -debug -unittest -od"$(IntDir)" d:\D\dmd\bin\dmd.exe -g
Im using MSDEV the $() above are replaced by the file names involved. Regan. -- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Jun 20 2004
On Sun, 20 Jun 2004 22:51:52 -0700, Walter <newshound digitalmars.com> wrote:I don't know what it's doing. Perhaps putting some strategic printf's will help pin down where it's spending the time.
This is the main I am using... int main() { printf("DONE\n"); return 0; } it's spending all it's time *after* the return 0."Regan Heath" <regan netwin.co.nz> wrote in message news:opr9w96man5a2sq9 digitalmars.com...When I compile tiger (the crypto algorithm) with a main fn that simply prints DONE and exits, then run it, it runs, uses 1MB memory, prints DONE, then keeps running for another 90 seconds, uses another 14MB of memory, before returning to the command prompt. What is it doing? This only happens in a debug build. My compile/link options are: d:\D\dmd\bin\dmd.exe -c "$(InputPath)" -g -gt -debug -unittest -od"$(IntDir)" d:\D\dmd\bin\dmd.exe -g
Im using MSDEV the $() above are replaced by the file names involved. Regan. -- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
-- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Jun 21 2004
J C Calvarese <jcc7 cox.net> Regan Heath wrote:On Sun, 20 Jun 2004 22:51:52 -0700, Walter <newshound digitalmars.com> wrote:I don't know what it's doing. Perhaps putting some strategic printf's will help pin down where it's spending the time.
This is the main I am using... int main() { printf("DONE\n"); return 0; } it's spending all it's time *after* the return 0.
Yes, that's perplexing. This is a stab-in-the-dark guess (from someone who often doesn't know what he's talking aobut), but could it be class destructors? Have you tried putting printfs in ~this functions? Maybe something slow is secretly happening in there. Just an idea. If you could post some code (or remind us where it is if it's already posted), you might get more creative suggestions."Regan Heath" <regan netwin.co.nz> wrote in message news:opr9w96man5a2sq9 digitalmars.com...When I compile tiger (the crypto algorithm) with a main fn that simply prints DONE and exits, then run it, it runs, uses 1MB memory, prints DONE, then keeps running for another 90 seconds, uses another 14MB of memory, before returning to the command prompt. What is it doing? This only happens in a debug build. My compile/link options are: d:\D\dmd\bin\dmd.exe -c "$(InputPath)" -g -gt -debug -unittest -od"$(IntDir)" d:\D\dmd\bin\dmd.exe -g
"$(IntDir)\*.obj" -of"$(OutDir)\$(WkspName).exe"Im using MSDEV the $() above are replaced by the file names involved. Regan. -- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
-- Justin (a/k/a jcc7) http://jcc_7.tripod.com/d/
Jun 21 2004
Regan Heath wrote:When I compile tiger (the crypto algorithm) with a main fn that simply prints DONE and exits, then run it, it runs, uses 1MB memory, prints DONE, then keeps running for another 90 seconds, uses another 14MB of memory, before returning to the command prompt. What is it doing? This only happens in a debug build. My compile/link options are: d:\D\dmd\bin\dmd.exe -c "$(InputPath)" -g -gt -debug -unittest -od"$(IntDir)"
The same thing was happening to me too, i think i concluded it was because of -gt.d:\D\dmd\bin\dmd.exe -g "$(IntDir)\*.obj" -of"$(OutDir)\$(WkspName).exe" Im using MSDEV the $() above are replaced by the file names involved. Regan.
Jun 21 2004
On Tue, 22 Jun 2004 00:54:24 +0200, Ivan Senji <ivan.senji public.srce.hr> wrote:Regan Heath wrote:When I compile tiger (the crypto algorithm) with a main fn that simply prints DONE and exits, then run it, it runs, uses 1MB memory, prints DONE, then keeps running for another 90 seconds, uses another 14MB of memory, before returning to the command prompt. What is it doing? This only happens in a debug build. My compile/link options are: d:\D\dmd\bin\dmd.exe -c "$(InputPath)" -g -gt -debug -unittest -od"$(IntDir)"
The same thing was happening to me too, i think i concluded it was because of -gt.
Maybe.. I have just found the problem, check out my dir listing... 06/16/2004 12:54p 8,648 sboxes.obj 06/16/2004 01:33p 1,848 sha.obj 06/22/2004 12:40p 13,114 tiger.obj 06/16/2004 01:07a 3,483,979 debug.log 06/21/2004 03:06p 31,728,643 trace.log 06/21/2004 03:06p 9,134,636 trace.def 06/22/2004 12:40p 4,433 string.obj 06/17/2004 09:41a 4,304 tohex.obj 06/22/2004 12:40p 1,970 sha1.obj 06/16/2004 12:44a 299,520 arr.txt 06/22/2004 12:40p 10,189 tigerboxes.obj 06/22/2004 12:40p 5,542 faststring.obj 06/22/2004 12:40p 765 build.obj 06/22/2004 12:40p 179,804 build.exe This contains some extra .obj files which are linked but not actually needed, oops. But also check out the size of the trace.log and trace.def files!? Deleting all these files and rebuilding gives... 06/22/2004 12:44p 10,189 tigerboxes.obj 06/22/2004 12:44p 13,114 tiger.obj 06/22/2004 12:44p 4,433 string.obj 06/22/2004 12:44p 1,970 sha1.obj 06/22/2004 12:44p 5,542 faststring.obj 06/22/2004 12:44p 765 build.obj 06/22/2004 12:44p 166,080 build.exe 06/22/2004 12:42p 10,006 trace.log 06/22/2004 12:42p 1,717 trace.def Which looks much better. And does not exhibit the behaviour. I have kept a copy of the bogus files, in case Walter wants to look into how they came about. Regan.d:\D\dmd\bin\dmd.exe -g "$(IntDir)\*.obj" -of"$(OutDir)\$(WkspName).exe" Im using MSDEV the $() above are replaced by the file names involved. Regan.
-- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Jun 21 2004
Oh, -gt is your culprit. -gt turns on trace dynamic profiling, see www.digitalmars.com/ctg/trace.html "Regan Heath" <regan netwin.co.nz> wrote in message news:opr9y0sp0c5a2sq9 digitalmars.com...On Tue, 22 Jun 2004 00:54:24 +0200, Ivan Senji <ivan.senji public.srce.hr> wrote:Regan Heath wrote:When I compile tiger (the crypto algorithm) with a main fn that simply prints DONE and exits, then run it, it runs, uses 1MB memory, prints DONE, then keeps running for another 90 seconds, uses another 14MB of memory, before returning to the command prompt. What is it doing? This only happens in a debug build. My compile/link options are: d:\D\dmd\bin\dmd.exe -c "$(InputPath)" -g -gt -debug -unittest -od"$(IntDir)"
The same thing was happening to me too, i think i concluded it was because of -gt.
Maybe.. I have just found the problem, check out my dir listing... 06/16/2004 12:54p 8,648 sboxes.obj 06/16/2004 01:33p 1,848 sha.obj 06/22/2004 12:40p 13,114 tiger.obj 06/16/2004 01:07a 3,483,979 debug.log 06/21/2004 03:06p 31,728,643 trace.log 06/21/2004 03:06p 9,134,636 trace.def 06/22/2004 12:40p 4,433 string.obj 06/17/2004 09:41a 4,304 tohex.obj 06/22/2004 12:40p 1,970 sha1.obj 06/16/2004 12:44a 299,520 arr.txt 06/22/2004 12:40p 10,189 tigerboxes.obj 06/22/2004 12:40p 5,542 faststring.obj 06/22/2004 12:40p 765 build.obj 06/22/2004 12:40p 179,804 build.exe This contains some extra .obj files which are linked but not actually needed, oops. But also check out the size of the trace.log and trace.def files!? Deleting all these files and rebuilding gives... 06/22/2004 12:44p 10,189 tigerboxes.obj 06/22/2004 12:44p 13,114 tiger.obj 06/22/2004 12:44p 4,433 string.obj 06/22/2004 12:44p 1,970 sha1.obj 06/22/2004 12:44p 5,542 faststring.obj 06/22/2004 12:44p 765 build.obj 06/22/2004 12:44p 166,080 build.exe 06/22/2004 12:42p 10,006 trace.log 06/22/2004 12:42p 1,717 trace.def Which looks much better. And does not exhibit the behaviour. I have kept a copy of the bogus files, in case Walter wants to look into how they came about. Regan.d:\D\dmd\bin\dmd.exe -g "$(IntDir)\*.obj" -of"$(OutDir)\$(WkspName).exe" Im using MSDEV the $() above are replaced by the file names involved. Regan.
-- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Jun 21 2004
On Mon, 21 Jun 2004 19:13:26 -0700, Walter <newshound digitalmars.com> wrote:Oh, -gt is your culprit. -gt turns on trace dynamic profiling, see www.digitalmars.com/ctg/trace.html
Ahh... so basically every time I ran my program it wrote more to trace.log and trace.def and they just got bigger and bigger... So the linker uses trace.def to link the code intelligently. Neat. In that case do I ever need to look at trace.log? Is there a good app to use to do so? Regan."Regan Heath" <regan netwin.co.nz> wrote in message news:opr9y0sp0c5a2sq9 digitalmars.com...On Tue, 22 Jun 2004 00:54:24 +0200, Ivan Senji <ivan.senji public.srce.hr> wrote:Regan Heath wrote:When I compile tiger (the crypto algorithm) with a main fn that
prints DONE and exits, then run it, it runs, uses 1MB memory, prints DONE, then keeps running for another 90 seconds, uses another 14MB of memory, before returning to the command prompt. What is it doing? This only happens in a debug build. My compile/link options are: d:\D\dmd\bin\dmd.exe -c "$(InputPath)" -g -gt -debug -unittest -od"$(IntDir)"
The same thing was happening to me too, i think i concluded it was because of -gt.
Maybe.. I have just found the problem, check out my dir listing... 06/16/2004 12:54p 8,648 sboxes.obj 06/16/2004 01:33p 1,848 sha.obj 06/22/2004 12:40p 13,114 tiger.obj 06/16/2004 01:07a 3,483,979 debug.log 06/21/2004 03:06p 31,728,643 trace.log 06/21/2004 03:06p 9,134,636 trace.def 06/22/2004 12:40p 4,433 string.obj 06/17/2004 09:41a 4,304 tohex.obj 06/22/2004 12:40p 1,970 sha1.obj 06/16/2004 12:44a 299,520 arr.txt 06/22/2004 12:40p 10,189 tigerboxes.obj 06/22/2004 12:40p 5,542 faststring.obj 06/22/2004 12:40p 765 build.obj 06/22/2004 12:40p 179,804 build.exe This contains some extra .obj files which are linked but not actually needed, oops. But also check out the size of the trace.log and trace.def files!? Deleting all these files and rebuilding gives... 06/22/2004 12:44p 10,189 tigerboxes.obj 06/22/2004 12:44p 13,114 tiger.obj 06/22/2004 12:44p 4,433 string.obj 06/22/2004 12:44p 1,970 sha1.obj 06/22/2004 12:44p 5,542 faststring.obj 06/22/2004 12:44p 765 build.obj 06/22/2004 12:44p 166,080 build.exe 06/22/2004 12:42p 10,006 trace.log 06/22/2004 12:42p 1,717 trace.def Which looks much better. And does not exhibit the behaviour. I have kept a copy of the bogus files, in case Walter wants to look into how they came about. Regan.d:\D\dmd\bin\dmd.exe -g "$(IntDir)\*.obj" -of"$(OutDir)\$(WkspName).exe" Im using MSDEV the $() above are replaced by the file names involved. Regan.
-- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
-- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Jun 21 2004
"Regan Heath" <regan netwin.co.nz> wrote in message news:opr9zbumd15a2sq9 digitalmars.com...On Mon, 21 Jun 2004 19:13:26 -0700, Walter <newshound digitalmars.com> wrote:Oh, -gt is your culprit. -gt turns on trace dynamic profiling, see www.digitalmars.com/ctg/trace.html
Ahh... so basically every time I ran my program it wrote more to trace.log and trace.def and they just got bigger and bigger... So the linker uses trace.def to link the code intelligently. Neat. In that case do I ever need to look at trace.log?
If you want to performance tune your code, yes.Is there a good app to use to do so?
Your brain should do just fine <g>.
Jun 22 2004
On Tue, 22 Jun 2004 02:52:38 -0700, Walter <newshound digitalmars.com> wrote:"Regan Heath" <regan netwin.co.nz> wrote in message news:opr9zbumd15a2sq9 digitalmars.com...On Mon, 21 Jun 2004 19:13:26 -0700, Walter <newshound digitalmars.com> wrote:Oh, -gt is your culprit. -gt turns on trace dynamic profiling, see www.digitalmars.com/ctg/trace.html
Ahh... so basically every time I ran my program it wrote more to trace.log and trace.def and they just got bigger and bigger... So the linker uses trace.def to link the code intelligently. Neat. In that case do I ever need to look at trace.log?
If you want to performance tune your code, yes.
Not right now, but I can imagine wanting to in the future.Is there a good app to use to do so?
Your brain should do just fine <g>.
I was thinking more along the lines of a gui to display and sort the info in the trace.log. The 30 meg one I had was very hard to read with a text editor. :) Regan -- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Jun 22 2004