Is there a tool that tell your exactly how many byte your Executive is using at runtime. I need to know how much Windows Memory my program is using and so on, so I can try to reduce the number byte used through better coding. I know that i can open up System from the Control Panel and click performance... But it don't give you information to the Exact Number of Byte used. It only give you the amount of kilobyte the program is using....

Also is there a tool that tell you the speed of code. I read posts where other Coders use them so I guest they are out there some where but I don't know where to find them.

One other thing. this is the wrong heading for this question but while im here do someone know how to get all the text after the last Back Slash in a path string.

Example:

C:\Windows\Notepad.exe

I just want to get the words Notepad.exe
Posted on 2002-01-20 02:45:37 by cmax
cmax,

there is a procedure in the MASM32 library called "NameFromPath" that will do the second for you.

Regards,

hutch@movsd.com
Posted on 2002-01-20 02:52:46 by hutch--
I love that MASM32 library.

I got rid of a lot of API calls because of it....All that you said in my pass question Im now 70% on my way to doing things the right way at a very low level....I traded in a 100 edit boxes for Buffers and Regesters so far.

EDIT:

UNBELEABLE.... It worked Just Like That.....

Thanks again
Posted on 2002-01-20 03:50:42 by cmax
cmax, there's not much use in getting your memory usage in bytes,
as all memory allocations are done in chunks of 4k (because of the
IA32 feature called paging).

Also, in most small applications, your applications memory usage will
be minimal, but your application will still seem to take up multiple
megabytes, due to the DLLs you import. Don't be alarmed by this,
DLLs are shared resources - you use address space from your process,
but not additional physical memory.

Also note the difference between reserved and committed memory.
Reserved isn't bad, the committed memory is what you want to
concentrate on reducing (if necessary).
Posted on 2002-01-20 05:22:26 by f0dder
Hello f0dder

"multiple megabytes, due to the DLLs you import"
This may be one of the reason I'm look for tool..
I want to see some of the thing i can't see and learn how to clock codes. I hear people talking about clock cycles all the time.
Posted on 2002-01-20 11:11:53 by cmax
You probably can't get around optimizing your stuff without a basic
understanding of what's going on - have a look at agner fog's optimization
manual (http://www.agner.org).

If you want something to help you out, perhaps it's worth to check
out intel's VTune. It's made to assist you when profiling your apps.
Posted on 2002-01-20 11:17:16 by f0dder
f0dder,

You should not try and lead people up the garden path. :)

===========================
cmax, there's not much use in getting your memory usage in bytes, as all memory allocations are done in chunks of 4k (because of the IA32 feature called paging).
===========================


GlobalAlloc()
SysAllocStringByteLen()

Ho Hum, both of these are BYTE size memory allocation. Not all memory is available through VirtualAlloc().

Regards,

hutch@movsd.com
Posted on 2002-01-20 17:21:43 by hutch--
Hutch, I am very sorry, but at the end level, everything is handled
through VirtualAlloc. Yes, the various memory management functions
handle minor allocations inside the pages - this is true. I didn't mean
that every allocation *you* do when using eg HeapAlloc end up
allocating a whole page (they are rounded to *some* value though).
What I meant was that if your program grows one byte across a
page boundary, your program takes up a whole extra page of
memory. And that way it also doens't really matter if your program
is 2047 bytes or 2048 bytes - it will end up taking 4096 bytes anyway.

Sorry that I didn't explain down to this level...
Posted on 2002-01-20 17:37:05 by f0dder
Now that i got a better understanding of masm32 (not the best but much better than before) I'll be getting into agner, and intel stuff very shortly. It's getting easier and easer to understand . But it's about time.

Thanks Guys.
Posted on 2002-01-20 21:06:44 by cmax