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/

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/

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/

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/

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.
> 

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/

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/

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/

"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>.

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/