469,898 Members | 1,537 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,898 developers. It's quick & easy.

List<t> generic type - Fastest way to copy into an unmanaged array?

Hi, Im hoping someone can give me some advice.
Im doing some development using VS Whidbey 2005 beta 1.

Im about to implement some highly time critical code related to a
managed collection of floats.

I basically require the fastest way to convert a managed array of
floats into an unmanaged array of floats.

As far as the managed collection is implemented, ive read that the
following would be the most type-safe and efficient (no
boxing/unboxing):

List<float> myFloats

However, Ive also read that the Marshal.Copy method is an extremely
fast way of copying a tradional managed array into an unmanaged array.
But if i do this method (i,e use a tradional .net array), I have the
boxing/unboxing issues.

For this particular case, I must sacrifice all I can for conversion
speed.

Can anyone recommend the fastest way to store and convert an array of
floats (managed -> unmanaged)?

thanks for reading.
Nov 17 '05 #1
2 1914
Daniel,
Hi, Im hoping someone can give me some advice.
Im doing some development using VS Whidbey 2005 beta 1.

Im about to implement some highly time critical code related to a
managed collection of floats.

I basically require the fastest way to convert a managed array of
floats into an unmanaged array of floats.

As far as the managed collection is implemented, ive read that the
following would be the most type-safe and efficient (no
boxing/unboxing):

List<float> myFloats

However, Ive also read that the Marshal.Copy method is an extremely
fast way of copying a tradional managed array into an unmanaged array.
It is indeed.
But if i do this method (i,e use a tradional .net array), I have the
boxing/unboxing issues.


Huh? Why boxing here? As long as you use an array of float, you won't need
boxing/unboxing. Granted, you'll end up copying a value here and there from
the stack to the managed heap where the array is stored, but it definitely
does *not* imply boxing at all (unless you for some reason declare the array
as Object* __gc[], which you probably aren't doing).

--
Tomas Restrepo
to****@mvps.org

Nov 17 '05 #2
"Tomas Restrepo \(MVP\)" <to****@mvps.org> wrote in message news:<#g**************@TK2MSFTNGP14.phx.gbl>...
Daniel,
Hi, Im hoping someone can give me some advice.
Im doing some development using VS Whidbey 2005 beta 1.

Im about to implement some highly time critical code related to a
managed collection of floats.

I basically require the fastest way to convert a managed array of
floats into an unmanaged array of floats.

As far as the managed collection is implemented, ive read that the
following would be the most type-safe and efficient (no
boxing/unboxing):

List<float> myFloats

However, Ive also read that the Marshal.Copy method is an extremely
fast way of copying a tradional managed array into an unmanaged array.


It is indeed.
But if i do this method (i,e use a tradional .net array), I have the
boxing/unboxing issues.


Huh? Why boxing here? As long as you use an array of float, you won't need
boxing/unboxing. Granted, you'll end up copying a value here and there from
the stack to the managed heap where the array is stored, but it definitely
does *not* imply boxing at all (unless you for some reason declare the array
as Object* __gc[], which you probably aren't doing).

You're quite right. I mis-read documentation on array and collection
type boxing/unboxing.

Thankyou for your assistance.
Regards.
Nov 17 '05 #3

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

reply views Thread by Iron Moped | last post: by
44 posts views Thread by Zytan | last post: by
35 posts views Thread by Lee Crabtree | last post: by
2 posts views Thread by Fred Mellender | last post: by
11 posts views Thread by paul.gibson | last post: by
reply views Thread by Salome Sato | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.