<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
I think that because your chunk size is constant, the memory manager
just returns previous blocks to you. So fragmentation does not
occur.<br>
<br>
On 24/09/2010 01:52, Ross Levis wrote:
<blockquote cite="mid:030b01cb5b26$9bfa7b40$d3ef71c0$@com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<meta name="Generator" content="Microsoft Word 12 (filtered
medium)">
<style>
<!--
/* Font Definitions */
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0cm;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:purple;
        text-decoration:underline;}
span.EmailStyle17
        {mso-style-type:personal-compose;
        font-family:"Calibri","sans-serif";
        color:#1F497D;}
.MsoChpDefault
        {mso-style-type:export-only;}
@page Section1
        {size:612.0pt 792.0pt;
        margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.Section1
        {page:Section1;}
-->
</style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
<div class="Section1">
<p class="MsoNormal"><span style="font-size: 12pt; color:
rgb(31, 73, 125);">Just wanted
some opinions on how bad a practice this is!<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size: 12pt; color:
rgb(31, 73, 125);"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size: 12pt; color:
rgb(31, 73, 125);">I have written
a media player which uses a DLL to decode audio files.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size: 12pt; color:
rgb(31, 73, 125);"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size: 12pt; color:
rgb(31, 73, 125);">The DLL opens
an MP3 file for example, and sends back decoded raw audio,
usually in chunks of
4608 bytes (~20ms), but could be a different size.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size: 12pt; color:
rgb(31, 73, 125);"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size: 12pt; color:
rgb(31, 73, 125);">I need to
buffer this audio data for around 5 seconds (1 MB).<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size: 12pt; color:
rgb(31, 73, 125);"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size: 12pt; color:
rgb(31, 73, 125);">Rather than
writing a complicated circular buffer which feeds in one end
and is taken from
the other, I decided to simply allocate memory for each new
chunk and store a
link from one memory location to the next. The oldest
buffer is read and
memory released.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size: 12pt; color:
rgb(31, 73, 125);"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size: 12pt; color:
rgb(31, 73, 125);">So there is roughly
1 new memory space being allocated and 1 being destroyed
every 20ms or so, with
around 200 chunks being stored at any one time.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size: 12pt; color:
rgb(31, 73, 125);"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size: 12pt; color:
rgb(31, 73, 125);">I’m using
D7 with the FastMM4 memory manager.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size: 12pt; color:
rgb(31, 73, 125);"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size: 12pt; color:
rgb(31, 73, 125);">It is working
very well with very little CPU usage at all, which I was
surprised at. I’ve
always been under the impression that allocating memory is a
slow process.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size: 12pt; color:
rgb(31, 73, 125);"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size: 12pt; color:
rgb(31, 73, 125);">Thoughts?<o:p></o:p></span></p>
</div>
<br>
<br>
__________ Information from ESET NOD32 Antivirus, version of virus
signature database 5472 (20100923) __________<br>
<br>
The message was checked by ESET NOD32 Antivirus.<br>
<br>
<a moz-do-not-send="true" href="http://www.eset.com">http://www.eset.com</a><br>
<pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
NZ Borland Developers Group - Delphi mailing list
Post: <a class="moz-txt-link-abbreviated" href="mailto:delphi@delphi.org.nz">delphi@delphi.org.nz</a>
Admin: <a class="moz-txt-link-freetext" href="http://delphi.org.nz/mailman/listinfo/delphi">http://delphi.org.nz/mailman/listinfo/delphi</a>
Unsubscribe: send an email to <a class="moz-txt-link-abbreviated" href="mailto:delphi-request@delphi.org.nz">delphi-request@delphi.org.nz</a> with Subject: unsubscribe
__________ Information from ESET NOD32 Antivirus, version of virus signature database 5472 (20100923) __________
The message was checked by ESET NOD32 Antivirus.
<a class="moz-txt-link-freetext" href="http://www.eset.com">http://www.eset.com</a>
</pre>
</blockquote>
<br>
<br>
<div class="moz-signature">-- <br>
Regards<br>
<br>
<b>Rohit Gupta</b><br>
B.E. Elec., M.E., Mem IEEE, Member IET<br>
Technical Manager<br>
Computer Fanatics Ltd<br>
<br>
<b>Tel </b>4892280 <br>
<b>Fax </b>4892290 <br>
<b>Web </b><a>www.cfl.co.nz</a><br>
<hr>
This email and any attachments contain information, which is
confidential and may be subject to legal privilege and copyright.
If you are not the intended recipient, you must not use,
distribute or copy this email or attachments. If you have received
this in error, please notify us immediately by return email and
then delete this email and any attachments.</div>
</body>
</html>