Thread overview | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|
|
June 21, 2004 this was never answered... | ||||
---|---|---|---|---|
| ||||
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/
|
June 21, 2004 Re: this was never answered... | ||||
---|---|---|---|---|
| ||||
Posted in reply to Regan Heath | 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 "$(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/ |
June 21, 2004 Re: this was never answered... | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter | 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 > "$(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/ |
June 21, 2004 Re: this was never answered... | ||||
---|---|---|---|---|
| ||||
Posted in reply to Regan Heath | 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/ |
June 21, 2004 Re: this was never answered... | ||||
---|---|---|---|---|
| ||||
Posted in reply to Regan Heath | 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. > |
June 22, 2004 Re: this was never answered... | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ivan Senji | 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/ |
June 22, 2004 Re: this was never answered... | ||||
---|---|---|---|---|
| ||||
Posted in reply to Regan Heath | 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/ |
June 22, 2004 Re: this was never answered... | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter | 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 >> 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/ > > -- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/ |
June 22, 2004 Re: this was never answered... | ||||
---|---|---|---|---|
| ||||
Posted in reply to Regan Heath | "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>. |
June 22, 2004 Re: this was never answered... | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter | 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/ |
Copyright © 1999-2021 by the D Language Foundation