Prev: VC++2010 EXPRESS
Next: Manifest Hell - a thing of the past?
From: Giovanni Dicanio on 26 May 2010 11:56
"David Ching" <dc(a)remove-this.dcsoft.com> wrote:

> With VS 2010 and .NET 4, you can now write shell extensions in .NET.

Yes, one of the improvements in CLR of .NET 4 is the so called In-Process
Side-by-Side (Inproc SxS):

There is an entry on the CLR Team Blog:

http://blogs.msdn.com/b/clrteam/archive/2009/06/03/in-process-side-by-side-part1.aspx

and an article published on MSDN as well:

http://msdn.microsoft.com/en-us/magazine/ee819091.aspx

Giovanni


From: Joseph M. Newcomer on 28 May 2010 20:15
This is a common misconception: that if you free storage, the program will get smaller.
Read my essay on how storage allocators work (it's on my MVP Tips site). For all
practical purposes, the task manager tells you absolutely nothing useful about memory
resource usage.

I would be surprised if freeing memory actually made the memory footprint smaller. You
should not at all be surprised at this.
joe

On Tue, 25 May 2010 09:19:01 -0700, jc <jc(a)discussions.microsoft.com> wrote:

>
>Hello,
>
>I am developing a 64-bit MFC application using VC2008.
>I have a method, that once a user clicks a button,
>the "File Open" dialog box is displayed. The dialog
>box variable is declared locally in the method.
>
>I noticed (using Task Manager), that once the dialog box
>opens, the application memory usage increases from
>3 MB to 30 MB, but when the dialog box is closed, the
>memory usage does not decrease. Since, the dialog box
>variable is declared locally, shouldn't the memory decrease,
>because the dialog box variable is no longer in scope?
>
>Is the application leaking?
>
>TIA,
>-jc
Joseph M. Newcomer [MVP]
email: newcomer(a)flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Joseph M. Newcomer on 28 May 2010 20:18
It is a common newbie mistake to think that freeing storage will reduce the memory usage
reported by task manager. It is an equally common mistake to believe that task manager
actually tells you something even remotely useful.
joe

On Tue, 25 May 2010 16:01:19 -0700, "Tom Serface" <tom(a)camaswood.com> wrote:

>That's difficult to tell from task manager. If you leave it sit for a while
>and then do a refresh you should see the memory being returned, but often
>Windows caches the memory thinking you may call the same functionality
>again. I think the memory indicators in Task Manager are interesting, but
>not a good indication of what is really happening in your program alone.
>
>Tom
>
>"jc" <jc(a)discussions.microsoft.com> wrote in message
>news:78AE1A30-9259-4C79-A329-AA8749266852(a)microsoft.com...
>> Hello,
>>
>> I am developing a 64-bit MFC application using VC2008.
>> I have a method, that once a user clicks a button,
>> the "File Open" dialog box is displayed. The dialog
>> box variable is declared locally in the method.
>>
>> I noticed (using Task Manager), that once the dialog box
>> opens, the application memory usage increases from
>> 3 MB to 30 MB, but when the dialog box is closed, the
>> memory usage does not decrease. Since, the dialog box
>> variable is declared locally, shouldn't the memory decrease,
>> because the dialog box variable is no longer in scope?
>>
>> Is the application leaking?
>>
>> TIA,
>> -jc
Joseph M. Newcomer [MVP]
email: newcomer(a)flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
From: David Ching on 29 May 2010 12:19
"Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in message
news:u1n0061f02minauqnl7fk9pn2s7n9agmcb(a)4ax.com...
> For all
> practical purposes, the task manager tells you absolutely nothing useful
> about memory
> resource usage.
>

Then what utility will tell you how much memory is committed to your app at
any given time? Are you saying there is no easy way to roughly check for
memory leaks?

-- David

From: Joseph M. Newcomer on 30 May 2010 00:50
How much memory is committed, and how much is in use, are completely different concepts.
And the amount committed is rarely interesting.

The easy check for memory leaks is if Task Manager shows monotonically increasing memory
usage. However, the notion that once you load a program or use a feature, that the memory
will be "reclaimed" is usually ill-founded, and never has had any existence in reality. So
fact that you load something, and the footprint increases, is not unreasonable (although I
find the amount to be rather unusually large), but expecting it to go away is not
something you should expect.. Now if you run the dialog a second time, and the space goes
up by the same huge amount AGAIN, then there is a very real problem, not because the space
does not go down, but because the space usage is so massive. But running a test on one
event is not conclusive.

As pointed out, injecting DLLs will increase the memory footprint the first time they are
injected, but not the second time. The DLLs will not go away.

Once storage is allocated with new or malloc (using the default implementations of new),
it never goes away. But it can be freed (for example, using the default implemention of
delete), making the space available for reuse, but it is *not* returned to the kernel, and
it will still continue to count in the information presented by Task Manager.

Overall, Task Manager is next-to-useless for doing other than the most trivial examination
of resource usage, and most of the time it is worthless for any but the most gross
behavioral inspection.

Since the size goes up so massively, it might be worthwhile to see what modules are loaded
before and after. The process explorer utility from www.sysinternals.com will give you a
list of the DLLs that are loaded. (Note this is not Task Manager). Having a pre-growth
inventory and post-growth inventory of these DLLs would be one step in identifying the
problem. Then, you MUST bring up the dialog a second time, and see if there is another
massive increase in space which is not released. If it doesn't happen on the second time,
then it is probably once-only allocation for bringing up the dialog. And that's just how
it is going to be.

Another example of the total uselessness of Task Manager deals with the age-old question
"Why does my program get smaller when I minimize it?" Task Manager does not report honest
numbers in the first place, and the values it returns are essentially meaningless because
they do not represent actual memory footprint, and when it comes to data, none of these
programs can tell you how much space is available for allocation. If you allocate 20MB of
storage, in 100K blocks, then free them all, your memory footprint will NOT decrease at
all, but you will have 20MB of free space that can be reallocated for other purposes. So
in many cases you see a "high water mark" rather than any real picture of what is going
on.

I tend to ignore Task Manager if I care about how memory is being used. I will use
Process Explorer to understand code usage, and I will monitor the heap myself if I care
about how the heap space is being used. But only in the most crude metrics can Task
Manager *suggest* what *might* be going on. It doesn't tell you anything useful about
WHY, and that is all that matters.

I don't consider it a useful tool at all.
joe

On Sat, 29 May 2010 09:19:26 -0700, "David Ching" <dc(a)remove-this.dcsoft.com> wrote:

>
>"Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in message
>news:u1n0061f02minauqnl7fk9pn2s7n9agmcb(a)4ax.com...
>> For all
>> practical purposes, the task manager tells you absolutely nothing useful
>> about memory
>> resource usage.
>>
>
>Then what utility will tell you how much memory is committed to your app at
>any given time? Are you saying there is no easy way to roughly check for
>memory leaks?
>
>-- David
Joseph M. Newcomer [MVP]
email: newcomer(a)flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: VC++2010 EXPRESS
Next: Manifest Hell - a thing of the past?