//Making my own my_array with pointers
class MyClass
{
unsafe int* my_array;
}
//Instead of using the build in
class MyClass
{
int[] my_array;
}
[.net] unsafe arrays & some performance in c#?
Author
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:
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!
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.
Author
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:
I'm hoping the Properties don't impose any extra memory, since the MyClass will be used in large quantities.
Thx
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
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 ?
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.
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.
Quote:Original post by MichalsonQuote: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!
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
