CodingRendle & C#

 

Press Ctrl+Enter to quickly submit your post
Quick Reply  
 
 
  
 From:  Mikee  
 To:  ALL
35151.1 
Hi,

Wondering if you can help me with optimisations a bit.


Example 1
c# code:
 
if (this.collision != null)
{
  int count = collision.NumPrimitives;
  for (int i = 0; i < count; i++)
  {
     BoundingBox box = new BoundingBox();
     BoundingBoxHelper.AddPrimitive(collision.GetPrimitiveOldWorld(i), ref box);
  }
}
 


Example 2
c# code:
 
if (this.collision != null)
{
  int count = collision.NumPrimitives;
  BoundingBox box;
  for (int i = 0; i < count; i++)
  {
     box = new BoundingBox();
     BoundingBoxHelper.AddPrimitive(collision.GetPrimitiveOldWorld(i), ref box);
  }
}
 


Am I right in thinking that in Example 1, I'm allocating seperate memory for a whole bunch of objects, which are quickly found to be out of scope and then marked for garbage collection?

And in Example 2 I'm overwriting the same bit of memory with a new object, so less gets marked for garbage collection?

Is this right or am I being silly?

Also, second question.......

Example 1
c# code:
 
 public Vector3 Offset;
 


Example 2
c# code:
 
 public Vector3 Offset {
   get { return this.offset; }
   set { this.offset = value; }
 }
 private Vector3 offset;
 


Is Example 2 slightly slower? Does it use more memory?



I'm not very good with writing good code so i'm a bit lost :)

ta chuck
0/0
 Reply   Quote More 

 From:  THERE IS NO GOD BUT (RENDLE)  
 To:  Mikee     
35151.2 In reply to 35151.1 

First answer: AFAIK, there's no difference between the compiled code for those two examples. It is definitely the case that the new operator will always allocate new memory on the heap and the previous memory referenced by the variable will be deallocated and garbage collected.

 

Second answer: there is a certain amount of indirection involved with using properties as opposed to public fields, but it's really not severe enough to be worrying about optimising it. It's much better practice to use properties, as it makes your code more maintainable.

 

Are you actually having performance issues, or is this premature optimisation? The .NET runtime is pretty damn performant, and the garbage collector and property code are particularly good. And the C# compiler is one of the best optimising compilers ever, and a lot of the time you're better off using the simplest approach and letting it do its job.

 

On that note, are you using XNA 2.0, or the 3.0 beta? If you can, use the beta, as it allows you to use Visual C# 2008 and the C# 3.0 compiler, which is very, very good, and provides lots of coding shortcuts which often get optimised well.


Twinkle, twinkle, little star, I don't wonder what you are:
You're the cooling down of gases, forming into solid masses.
0/0
 Reply   Quote More 

 From:  Mikee  
 To:  THERE IS NO GOD BUT (RENDLE)     
35151.3 In reply to 35151.2 

Ah right. Thank you.

 

It's just premature optimisation.. I'm not trying to go all out with heavy optimisation and unreadable code everywhere.. we've only just started writing an actual framework for our game so I'm trying to work out a few things so I can start how I mean to go on - so I don't get a big headache at the end when we're trying to speed it up.

 

We're using XNA 2.0 for the game... Mostly because not all of us have VS2008 (well, we do at work but not at home which is where we do most of the development).

 

We could use Visual C# 2008 Express, but it lacks support for solutions which I can't live without.

 

To fire another question back at you - are there any .NET/C# tools that you can't live without?

 

I've been playing with NProf which seems pretty handy (well, I can see how it'd be handy as we get further on with development). Are there any nice tools that you use regularly?

0/0
 Reply   Quote More 

 From:  Mikee  
 To:  ALL
35151.4 
Yes, you saw it here first folks.. it look like just a bunch of badly shaded sheep rolling around randomly with broken physics.. but it's the start of something amazing ;)

Attachments:

0/0
 Reply   Quote More 

 From:  THERE IS NO GOD BUT (RENDLE)  
 To:  Mikee     
35151.5 In reply to 35151.3 

Unfortunately for you, most of the C# tools I use (unit testing, profiling, etc) are included within Visual Studio Team System 2008, which I get through work. But if you don't have that, then:

 

NUnit is pretty much essential for unit-testing.

 

I also use Lutz Roeder's Reflector for poking about in third party assemblies, and the CodeMetrics plug-in for that is highly recommended for quality checking.

 

Another good code analysis tool is devAdvantage, which has now gone open source on SourceForge.

 

When I'm optimising, I use ildasm (from the SDK) to look at the compiled IL code from two different ways of doing something to see which uses the fewest instructions.

 

If you're creating a framework, then you should use FxCop to check the code for best practices. And consider Microsoft's Sandcastle for generating really excellent documentation from the doc comments I know you'll be adding to all your public and protected members...


Twinkle, twinkle, little star, I don't wonder what you are:
You're the cooling down of gases, forming into solid masses.
0/0
 Reply   Quote More 

 From:  THERE IS NO GOD BUT (RENDLE)  
 To:  Mikee     
35151.6 In reply to 35151.3 
One other thought on optimisation: you will be tempted to believe that arrays are better than List<T>'s, and that for loops are better than foreach. Neither of these things are true.

The List<T> class is heavily optimised and often performs better than an array. If you are returning a list of items from a method purely for iteration, use IEnumerable<T> as the return type and the yield keyword in the method:

C# code:
public IEnumerable<Vector3> GetVectors()
{
  Vector3 v;
  while ((v = MakeVector()) != null)
  {
    yield return v;
  }
}
 
...
 
foreach (Vector3 v in GetVectors())
{
  // do something
  if (condition) break;
}


The C# compiler optimises the shit out of this kind of thing. It's co-processed, so each call to MakeVector only happens as you iterate through the foreach loop. If you break out of the foreach, the IEnumerable is destroyed, so you don't make unnecessary calls to MakeVector, which you might if you populated an entire array in advance. Also, if you implemented parallelism at some point in the future, the operation could be split across multiple cores.

Twinkle, twinkle, little star, I don't wonder what you are:
You're the cooling down of gases, forming into solid masses.
0/0
 Reply   Quote More 

 From:  Mikee  
 To:  THERE IS NO GOD BUT (RENDLE)     
35151.7 In reply to 35151.6 

Hmm. Interesting stuff. I think I've done something similar in the past, but probably just due to copying and pasting someone elses work.

 

Thanks for your help.

0/0
 Reply   Quote More 

 From:  Mikee  
 To:  ALL
35151.8 
Ok, I've got another one for you if you could be so kind.

Basically, we've extended the XNA framework slightly and bastardized it slightly to suit our needs.

In XNA the main 'Game' class calls methods.. (Initialize(), LoadContent(), Update(), Draw()). It calls update and draw x times per second.

We've set things up so that you add Screens to the main game class, then you add components to screens. Components also have their own list of components and they have their own list of components and so on.

When Update() is called in the main Game class, it'll call Update() on all the screens, which'll call Update() on all the Components and their components..etc..

So, a small example would be like this:

code:
 
Game    Screen        Component    Component
------- ------------- ------------ ----------
 
Game -> 3dScreen   -> Sheep     -> AI
                                -> Render
                                -> Physics
 
                   -> Dog       -> Controller
                                -> Animation
     -> MenuScreen -> Setup
     -> HUDScreen  -> Radar
                   -> Healthbar
 


Although we're not at the stage of making any actual game logic just yet, I know that components will need to talk to eachother and/or their parent component.

In an example of an engine that i've seen, they use this big messaging system to talk between components/screens, whereby components (or screens) can listen to a certian messages and will receive all messages of that type.

This seems all complicated to me and using events and eventhandlers seems like the way to go.

Can you think of a better way to do any of this? I'm also concerned about speed.. for example, would a onPositionChanged event on model (which can fire 100 times a second) be too much?
0/0
 Reply   Quote More 

 From:  THERE IS NO GOD BUT (RENDLE)  
 To:  Mikee     
35151.9 In reply to 35151.8 
I would certainly start by using event handlers, rather than reinventing the wheel. If you try to implement your own system, you risk problems with objects not getting dereferenced and garbage collected.

Twinkle, twinkle, little star, I don't wonder what you are:
You're the cooling down of gases, forming into solid masses.
0/0
 Reply   Quote More 

Reply to All    
 

1–9

Rate my interest:

Adjust text size : Smaller 10 Larger

Beehive Forum 1.5.2 |  FAQ |  Docs |  Support |  Donate! ©2002 - 2024 Project Beehive Forum

Forum Stats