Sign in to follow this  
bilsa

[.net] unsafe arrays & some performance in c#?

Recommended Posts

bilsa    157
Hi everyone! I was wondering if someone could explain the impact of using unsafe code in c# applications? I have been reading around some about unsafe pointers, and the only disadvantages of using them was readability of the code and the possibility of introduction of bugs? Compiling with unsafe code forces to use the 'unsafe' flag. But will this affect the rest of my managed code in some way? For example. Would this give me worse performance:

//Making my own my_array with pointers
class MyClass
{
    unsafe int* my_array;
}

//Instead of using the build in
class MyClass
{
    int[] my_array;
}





The latter one will derive directly from System.Array which should impose some extra memory overhead right? I know I loose all nifty functions built in System.Array, but in my case I really don't need them anyway... so I would gladly trade them for some extra memory. So, will this unsafe code impact giving MyClass and the rest of my managed code worse performance? Thank you! Btw, I might just as well shoot for this one: Does adding another function to a class increase the size of the objects? So, does it matter if I have 1 or 10 functions? C ya!

Share this post


Link to post
Share on other sites
ToohrVyk    1595
Quote:
Original post by bilsa
I have been reading around some about unsafe pointers, and the only disadvantages of using them was readability of the code and the possibility of introduction of bugs?


Yes, and the only disadvantages of drinking bleach are dying in horrible agony with large amounts of internal bleeding.

Quote:
So, will this unsafe code impact giving MyClass and the rest of my managed code worse performance?


There is no way for a human to guess if the code you wrote will be more or less optimized than the already highly optimized Array. There is also no way to tell if the difference in performance bears any importance (half a millisecond lost in the credits page cleanup code isn't going to be a problem). The only way to find out is to profile its general usage.

As a side note, are you certain that reworking arrays in this way is the most time-efficient way to save memory? You could easily save hours of work by using System.Array — hours of work you could then spend on optimizing high-level memory usage and gain megabytes of free memory (as opposed to a meager handful of bytes on each System.Array).

EDIT: the amount of functions does not increase memory usage.

Share this post


Link to post
Share on other sites
bilsa    157
Thanks ToohrVyk, I already bear that in mind.

As this is just a hoppy project, it doesn't really matter how many hours it will save and it doesn't really matter when/if the project will be done. It's purely for my satisfaction :)

And I think it would matter quite much in my case, since I want to have something more like this:


struct MyClass
{
int Val1 { get {return array[0]; } }
int Val2 { get {return array[1]; } }
int Val3 { get {return array[2]; } }

unsafe int* array; //this will hold three int's
}




I'm hoping the Properties don't impose any extra memory, since the MyClass will be used in large quantities.

Thx

Share this post


Link to post
Share on other sites
ToohrVyk    1595
Quote:
Original post by bilsa
*** Source Snippet Removed ***


Sounds like a waste of memory to me.

Why not:


struct TheStruct {
public int x;
public int y;
public int z;
}




Either way, you're usually better off macro-optimizing memory usage. By curiosity, what are these objects you're using, and why do you need so many ? And how many, actually ? More than 6 million ?

Share this post


Link to post
Share on other sites
RenZimE    128
well the performance can go either way, and can still cause memory leaks if not dealt with properly, i would suggest using IntPtr for your needs as it can then still be used for what ever you want to use a pointer for, and the GC will still collect it when its no longer referenced.

Share this post


Link to post
Share on other sites
Michalson    1657
Quote:
Original post by bilsa
Thanks ToohrVyk, I already bear that in mind.

As this is just a hoppy project, it doesn't really matter how many hours it will save and it doesn't really matter when/if the project will be done. It's purely for my satisfaction :)

And I think it would matter quite much in my case, since I want to have something more like this:

*** Source Snippet Removed ***

I'm hoping the Properties don't impose any extra memory, since the MyClass will be used in large quantities.

Thx


Lets see, instead of just having 3 int variables (12 bytes), you're proposing having an unsafe array, which stores the 3 ints, which are then accessed via functions as if they where individual int variables.

So you've managed to:
-Add at least 4 extra bytes per instance (the pointer to the array)
-Add the overhead of calculating the offset from the array base pointer everytime you want to read/write from one of your shadow variables.
-Make your entire application hard to debug and likely to experience unexplained crashes

In return for the benefit of:
-Absolutely nothing, apart from prematurely trying to micro optimize

You'll just have to trust us on this, but you are not going in the right direction. For the moment you do not understand enough about performance or the underlying mechanics of your compiler to be micro optimizing at any time, let alone before you've really got the code to profile against. Just because you think you're going to be using "lots" of something doesn't mean you should try to micro optimize it like this. Write the application first, the right way, with safe, readable, non-hacked together code. Once your program works, then profile to see where the memory/performance bottlenecks are.

Share this post


Link to post
Share on other sites
Washu    7829
Quote:
Original post by Michalson
Quote:
Original post by bilsa
Thanks ToohrVyk, I already bear that in mind.

As this is just a hoppy project, it doesn't really matter how many hours it will save and it doesn't really matter when/if the project will be done. It's purely for my satisfaction :)

And I think it would matter quite much in my case, since I want to have something more like this:

*** Source Snippet Removed ***

I'm hoping the Properties don't impose any extra memory, since the MyClass will be used in large quantities.

Thx


Lets see, instead of just having 3 int variables (12 bytes), you're proposing having an unsafe array, which stores the 3 ints, which are then accessed via functions as if they where individual int variables.

So you've managed to:
-Add at least 4 extra bytes per instance (the pointer to the array)
-Add the overhead of calculating the offset from the array base pointer everytime you want to read/write from one of your shadow variables.
-Make your entire application hard to debug and likely to experience unexplained crashes

In return for the benefit of:
-Absolutely nothing, apart from prematurely trying to micro optimize

You'll just have to trust us on this, but you are not going in the right direction. For the moment you do not understand enough about performance or the underlying mechanics of your compiler to be micro optimizing at any time, let alone before you've really got the code to profile against. Just because you think you're going to be using "lots" of something doesn't mean you should try to micro optimize it like this. Write the application first, the right way, with safe, readable, non-hacked together code. Once your program works, then profile to see where the memory/performance bottlenecks are.


Aye, and after doing that you might find that algorithmic improvements will significantly improve performance AND memory usage. A good read on just such an occurance would be Rico Mariani's Performance Todbits, especially: Performance Quiz #6 -- Chinese/English Dictionary reader

Tis a great read, and it demonstrates how very minor changes in a .net application can improve memory usage and performance without sacrificing code readability, testability, and usability!

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this