Memory profile not accurate, has problems running program

I have a program that doesn't work well with the ANTS memory profiler. I have to reboot my computer, and then ANTS profiler will only do 1 memory profile. After that, it just starts the process for my program, but it never gets any CPU time (CPU time of 0:00:00), nor does it allocate more memory.

However, the performance profiling works well, running each time, and generating sane results.


My program, on start creates 64 Microsoft.DirectX.DirectSound.SecondaryBuffers, each holding 160,000 samples.

Here is the code that fills these buffers:
....


for(a=0;a<sampleEnd;a++)
{
	t+=step;
	val=16384.0*Math.Sin(w*t+phi);
	//ar.Add((short)val);
	ar[a]=(short)val;
}
sound=new SecondaryBuffer(bufdesc,device);
sound.Write(0,ar,Microsoft.DirectX.DirectSound.LockFlag.EntireBuffer);
sound.Volume=0;
sound.Frequency=frequency;
sounds.Add(sound);


...

According to the performance profiling, the lines inside the loop are run 10,240,000 times, and the code around that loop is run 64 times.

After the end of this code, the ArrayList sounds holds 64 SecondaryBuffers each holding 160,000 samples of 2 bytes each. Therefore, sounds should be 20 MB in size. However, from the ANTS profiler report, sounds is only 4,904 bytes with the children, and holds 64 objects of SecondaryBuffer type.

My thoughts is that the discrepency is due to the fact that Microsoft.DirectX.DirectSound.SecondaryBuffer doesn't have the debug info. This causes ANTS profiler to report that my program is only using 630 KB instead of the expected 20MB.

.NET Framework version: 1.0.3705
DirectX Version: 9.0 (April 2005) Assembly Version 1.0.900.0

Comments

  • Brian DonahueBrian Donahue Posts: 6,590 New member
    Hello,

    I'm sure that the debug information has nothing to do with the issue. This may be the case with performance profiling, which allows you to filter only on methods that have source code.

    In memory profiling, however, the allocations are taken out of the .NET runtime. I think that SecondaryBuffer could be a pointer only and the actual data resides somewhere else.

    Can you locate one of the SecondaryBuffer objects in the all objects list, look at the Hierarchy tab at the bottom of the screen, and see if it refers to another object? My guess is that SecondaryBuffer will refer you to a Byte[] object that is 320K in size.
  • The only pointer that the SecondaryBuffer holds is the pointer to the Microsoft.DirectX.DirectSound.Device, which is 24 bytes.

    When I sort the objects in the "All" object view by size, the biggest item is a 65K Byte[] that was allocated by XmlSerializer.

    If I look at the SecondaryBuffer in the Visual Studio debugger, I can't see the data as I can with an array, which probably means that the SecondaryBuffer isn't managed code, at least for the data storage.
  • Hi there,

    my name is Tom Harris; I'm responsible for the development of ANTS Profiler here at Red Gate. I was interested to see that you are using the product with the managed DirectX libraries. I think that you have now realized where the problem lies - the actual memory is not being allocated by managed code. This is because the Microsft.DirectX.DirectSound assembly is basically just a .NET wrapper over the native implementation.

    ANTS Profiler can only profile the memory and peformance of .NET code. You will need to get a memory profiler for native code if you want to investigate the actual memory usage under the hood.

    Best regards,

    Tom
This discussion has been closed.