Windows Vista Forums
Vista Forums Home Join Vista Forums Windows 7 Forum Vista Tutorials Tags
Welcome to Windows Vista Forums. Our forum is dedicated to helping you find solutions with any problems, errors or issues you are experiencing with Windows Vista. The Vista forum also covers news and updates and has an extensive Windows Vista tutorial section that covers a wide range of tips and tricks.

Go Back   Vista Forums > Misc Newsgroups > .NET General

Vista - Serialization optimization

Reply
 
Old 12-10-2008   #1 (permalink)
guy1976


 
 

Serialization optimization

Hi

I have an object :

[Serializable]
public class Buffer
{
private int length;
private IntPtr buffer;
}


The buffer field is allocated from an unmanaged memory (via a COM
object).

What I'd like to do, is to serialize this object w/o needing to
convert the IntPtr to byte[] (in the GetObjectData method), the
reasons are :
1. To ease on the GC (reduce allocations/sec and induced GC/sec )
2. buffer can be very large (128KB)
3. Reduce Marshal.Copy


Any idea how?
I was thinking on memory pool, but there is a constrain that this
object is transfered via remoting, and I cannot waist b/w for sending
un-used data.


Thanks
Guy.



My System SpecsSystem Spec
Old 12-10-2008   #2 (permalink)
Jeroen Mostert


 
 

Re: Serialization optimization

guy1976@xxxxxx wrote:
Quote:

> I have an object :
>
> [Serializable]
> public class Buffer
> {
> private int length;
> private IntPtr buffer;
> }
>
>
> The buffer field is allocated from an unmanaged memory (via a COM
> object).
>
> What I'd like to do, is to serialize this object w/o needing to
> convert the IntPtr to byte[] (in the GetObjectData method), the
> reasons are :
> 1. To ease on the GC (reduce allocations/sec and induced GC/sec )
> 2. buffer can be very large (128KB)
> 3. Reduce Marshal.Copy
>
>
> Any idea how?
You can efficiently access unmanaged memory by using unsafe code to access a
pointer directly ("unsafe { byte* p = (byte*) buffer.ToPointer(); }"), which
eliminates the need for copying.

You can use the StreamingContext.State property to determine what you're
remoting to. If you're remoting in the same process (that is, between
AppDomains), you could choose not to copy/serialize the buffer at all, but
instead remote the pointer directly. Be aware that this is contrary to the
usual semantics of serialization if the receiver changes the contents of the
memory, as the sender isn't isolated from this.

Between local processes, you can remote file mapping handles (as created by
CreateFileMapping()). You can use permissions to restrict the accessibility
in this case, preventing remote clients from changing the passed buffer
(this is still contrary to the serialization semantics, just in a different
way).

These solutions are all less intuitive and less safe than simply remoting
the bytes, so make sure you're not optimizing prematurely. In particular,
reducing remoting as much as possible is more effective than making the
remoting itself more efficient, so only tackle the second if you've
sufficiently tackled the first.

--
J.
My System SpecsSystem Spec
Old 12-11-2008   #3 (permalink)
guy1976


 
 

Re: Serialization optimization

On 10 Dec, 21:27, Jeroen Mostert <jmost...@xxxxxx> wrote:
Quote:

> guy1...@xxxxxx wrote:
Quote:

> > I have an object :
>
Quote:

> > [Serializable]
> > public class Buffer
> > {
> > * * * * private int length;
> > * * * * private IntPtr buffer;
> > }
>
Quote:

> > The buffer field is allocated from an unmanaged memory (via a COM
> > object).
>
Quote:

> > What I'd like to do, is to serialize this object w/o needing to
> > convert the IntPtr to byte[] (in the GetObjectData method), the
> > reasons are :
> > 1. To ease on the GC (reduce allocations/sec and induced GC/sec )
> > 2. buffer can be very large (128KB)
> > 3. Reduce Marshal.Copy
>
Quote:

> > Any idea how?
>
> You can efficiently access unmanaged memory by using unsafe code to access a
> pointer directly ("unsafe { byte* p = (byte*) buffer.ToPointer(); }"), which
> eliminates the need for copying.
>
> You can use the StreamingContext.State property to determine what you're
> remoting to. If you're remoting in the same process (that is, between
> AppDomains), you could choose not to copy/serialize the buffer at all, but
> instead remote the pointer directly. Be aware that this is contrary to the
> usual semantics of serialization if the receiver changes the contents of the
> memory, as the sender isn't isolated from this.
>
> Between local processes, you can remote file mapping handles (as created by
> CreateFileMapping()). You can use permissions to restrict the accessibility
> in this case, preventing remote clients from changing the passed buffer
> (this is still contrary to the serialization semantics, just in a different
> way).
>
> These solutions are all less intuitive and less safe than simply remoting
> the bytes, so make sure you're not optimizing prematurely. In particular,
> reducing remoting as much as possible is more effective than making the
> remoting itself more efficient, so only tackle the second if you've
> sufficiently tackled the first.
>
> --
> J.- Hide quoted text -
>

1.How will the byte* elimite the copying?
2.I'm doing remoting between two computers
3.I must optimize because GC is working too much
Quote:

> - Show quoted text -
My System SpecsSystem Spec
Old 12-11-2008   #4 (permalink)
Jeroen Mostert


 
 

Re: Serialization optimization

guy1976@xxxxxx wrote:
Quote:

> On 10 Dec, 21:27, Jeroen Mostert <jmost...@xxxxxx> wrote:
Quote:

>> guy1...@xxxxxx wrote:
Quote:

>>> I have an object :
>>> [Serializable]
>>> public class Buffer
>>> {
>>> private int length;
>>> private IntPtr buffer;
>>> }
>>> The buffer field is allocated from an unmanaged memory (via a COM
>>> object).
>>> What I'd like to do, is to serialize this object w/o needing to
>>> convert the IntPtr to byte[] (in the GetObjectData method), the
>>> reasons are :
>>> 1. To ease on the GC (reduce allocations/sec and induced GC/sec )
>>> 2. buffer can be very large (128KB)
>>> 3. Reduce Marshal.Copy
>>> Any idea how?
>> You can efficiently access unmanaged memory by using unsafe code to access a
>> pointer directly ("unsafe { byte* p = (byte*) buffer.ToPointer(); }"), which
>> eliminates the need for copying.
>>
>> You can use the StreamingContext.State property to determine what you're
>> remoting to. If you're remoting in the same process (that is, between
>> AppDomains), you could choose not to copy/serialize the buffer at all, but
>> instead remote the pointer directly. Be aware that this is contrary to the
>> usual semantics of serialization if the receiver changes the contents of the
>> memory, as the sender isn't isolated from this.
>>
>> Between local processes, you can remote file mapping handles (as created by
>> CreateFileMapping()). You can use permissions to restrict the accessibility
>> in this case, preventing remote clients from changing the passed buffer
>> (this is still contrary to the serialization semantics, just in a different
>> way).
>>
>> These solutions are all less intuitive and less safe than simply remoting
>> the bytes, so make sure you're not optimizing prematurely. In particular,
>> reducing remoting as much as possible is more effective than making the
>> remoting itself more efficient, so only tackle the second if you've
>> sufficiently tackled the first.
>
> 1.How will the byte* elimite the copying?
It will eliminate copying in those cases where you would access the bytes
but not store them somewhere else. For .GetObjectData(), it's of little to
no use because you can't serialize individual bytes (well, you can, you just
don't want to) and you can't really use a more efficient representation than
a byte array either
Quote:

> 2.I'm doing remoting between two computers
Then you have no choice but to remote the data as copied bytes.
Quote:

> 3.I must optimize because GC is working too much
How do you know what's "too much"? I'm skeptical. If you need to copy a lot
of data every second, you need to copy a lot of data every second. You can't
optimize away your core function.

Consider not remoting "buffer". Remote byte arrays directly instead. This
way you are at least sure that the bytes are only copied once to a managed
object -- every subsequent remoting call (if there is more than one) can
simply take the byte array.

Consider ways to eliminate the remoting altogether (you don't have to use
remoting, even if it's convenient -- you could stream the bytes directly
over a socket, for example). Consider ways to make the individual remoting
packets smaller (less than 85 KB will avoid the Large Object Heap) or larger
(so there are less allocations).

Beyond this general advice, it's hard to say anything. There is no magic bullet.

--
J.
My System SpecsSystem Spec
Reply

Thread Tools


Similar Threads
Thread Forum
Anyone know what .NET Runtime Optimization Service is? General Discussion
BIOS Optimization Guide Overclocking & Cooling
How important is x64 optimization? General Discussion
Page File Optimization General Discussion
Optimization? Overclocking & Cooling


Vista Forums is an independent web site and has not been authorized,
sponsored, or otherwise approved by Microsoft Corporation.
"Windows Vista", the Start Orb, and related materials are trademarks of Microsoft Corp.
© Designer Media Ltd

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46