Re: Fast way to allocate buffer for producer/consumer scenario
- From: "James Brown" <not@home>
- Date: Mon, 9 Jan 2006 15:17:58 -0000
"Ulrich Eckhardt" <eckhardt@xxxxxxxxxxxxxx> wrote in message
news:bq1a93-fa6.ln1@xxxxxxxxxxxxxxxxxxxxxxxxx
> Hi!
>
> The topic already says most of what I want, but here is a slightly more
> verbose explanation:
> I have a thread that performs network service by simply reading from a
> socket. At the moment, it then copies the received data into the internal
> queue and triggers another thread to handle the received data. The size of
> the received data ranges from around 6 bytes to 500 bytes for 98% of all
> cases but other, rare cases being even in the range of a few megabytes.
>
> What I now did was to restructure this so that instead of copying the
> buffer
> to the queue, the data is moved into the queue, i.e. the queue assumes
> ownership of the buffer and the network service thread allocates a new
> buffer for the next transfer.
>
> During that, I noticed that the performance strongly depends on the way
> the
> buffers are allocated, which is why I wanted to ask for the best way to do
> it. I guess that the probably fastest way would be a dedicated memory
> pool,
> i.e. one that is used only for this transfer. However, this is not a
> trivial task a) to get right and b) to test that you got it right, so I'd
> rather not do this but build on a good system-provided way.
>
> I have at this moment tried GlobalAlloc, VirtualAlloc and 'operator new'.
> All three of them had a comparable performance but I'm not satisfied with
> either of them. GlobalAlloc() is marked as obsolete and slower than
> VirtualAlloc(), which is supposed to replace it. VirtualAlloc() however
> interoperates with the OS to reserve pages in virtual and physical memory,
> which in itself presents an overhead. Doing so repeatedly seems like a lot
> of overhead to me, I'd rather recycle the pages inside the process before
> interacting with the OS. 'operator new' does exactly that, but it uses a
> bytesize granularity instead of a pagesize granularity which imposes a
> certain overhead.
>
> I have taken a look at the heap functions for creating and accessing a
> heap,
> is that perhaps the right approach? To be honest, this API seems to be
> quite complicated, which is why I ask here first if it would solve my
> problems.
>
> Any suggestions anyone?
>
> Uli
>
HeapAlloc is the recommended method. recent versions of Windows
have shown a dramatically improved heap-allocation performance. Which
version of Windows are you basing your tests on?
The compiler you are using will also influence memory-allocation speeds,
if you are using the c-runtime new/malloc routines. Although VC6.0
was quite good in this area, newer versions of visual-studion (i.e.
2003/2005)
have better memory-management routines.
It is unlikely that you will be able to code a better malloc() that is
already available,
but if you have very specific requirements (such as always allocating
500bytes
at a time as you mention) then maybe a custom allocator would be suitable.
You could replace the global-new operator with your own version and have
no impact on the rest of your program design.
A network service type program suggests to me a circular buffer type
arrangement because your packets aren't going to be in memory
for ever are they? Just allocate yourself a large buffer (i.e. 1Mb)
and maintain circular queue pointers, with older packets being overwritten
by new packets as they arrive.
James
--
Microsoft MVP - Windows SDK
www.catch22.net
Free Win32 Source and Tutorials
.
- References:
- Fast way to allocate buffer for producer/consumer scenario
- From: Ulrich Eckhardt
- Fast way to allocate buffer for producer/consumer scenario
- Prev by Date: Re: Start a new process WITH a visible window from a service?
- Next by Date: Re: Start a new process WITH a visible window from a service?
- Previous by thread: Re: Fast way to allocate buffer for producer/consumer scenario
- Next by thread: Re: Fast way to allocate buffer for producer/consumer scenario
- Index(es):
Relevant Pages
|
