2

I'm building an application that is seriously slower than it should be (a process takes 4 seconds when it should take only .1 seconds, that's my goal at least).

I have a bunch of methods that pass an array from one to the other. This has kept my code nice and organized, but I'm worried that it's killing the efficiency of my code.

Can anyone confirm if this is the case?

Also, I have all of my code contained in a class separate from my UI. Is this going make things run significantly slower than if I had my code contained in the Form1.cs file?

Edit: There are about 95000 points that need to be calculated, each point goes through 7 methods that does additional calculations.

sooprise
  • 22,657
  • 67
  • 188
  • 276
  • 4
    You are going to have to give us more information. 4 seconds is extremely slow unless you are doing millions of iterations. – Byron Whitlock Aug 06 '10 at 17:54
  • 2
    Maybe you could give us a sample. There are tons of things that could cause issues like this. – Matthew Whited Aug 06 '10 at 17:55
  • 1
    Arrays are passed by reference, not value, so it's not a "copying" that is slowing your code down (since the array **ISN'T** copied). – myermian Aug 06 '10 at 17:55
  • 2
    Also, rename `Form1.cs`. Even something like `MainForm.cs` would be preferred, because you can tell later what it is, if and when you have many more forms. Try for names like `DatabaseForm`, `LoginForm`, `UserEditorForm`, or whatever it does. – dlras2 Aug 06 '10 at 17:56
  • Method invocation is among the slowest opcodes in the CLR, but Byron is right that this shouldn't come into play except in extremely iterative scenarios. – Kirk Woll Aug 06 '10 at 17:56
  • I agree with Matthew. Some sample code would be good. – Sean Aug 06 '10 at 20:07

7 Answers7

11

Have you tried any profiling or performance tools to narrow down why the slowdown occurs?

It might show you ways that you could use to refactor your code and improve performance.

This question asked by another user has several options that you can choose from:

Good .Net Profilers

Community
  • 1
  • 1
Jamie Keeling
  • 9,806
  • 17
  • 65
  • 102
  • Bare minimum would be a code sample... profiling is great but some (I'd contend most) performance issues can be found in a glance. – Matthew Whited Aug 06 '10 at 18:21
  • @Matthew: Sometimes, in little programs, maybe. I've seen people write `for (i = 0; i < a.Count; i++) cout << a[i];` and wonder if writing `++i` would help, or wondering if the compiler would optimize out the `a.Count` to make it go faster. (Hint: 99.99% of time is in `cout`.) – Mike Dunlavey Aug 06 '10 at 23:22
  • @Soo: The answers to listen to are the ones that say "profile - don't guess". I use the manual pause technique, which is very effective in any language, including C#. You say it's taking 40 times longer than you expect? Then you're guaranteed to see the problem(s) if you pause it a few times. Here's why: http://stackoverflow.com/questions/1777556/alternatives-to-gprof/1779343#1779343 – Mike Dunlavey Aug 07 '10 at 12:48
10

No. This is not what is killing your code speed, unless many methods means like a million or something. You probably have more things iterating through your array than you need or realize, and the array itself may have a larger memory footprint than you realize.

Perhaps you should look into a design where instead of passing the array to 7 methods, you iterate the array once, passing the members to 7 methods, this will minimize the number of times you're iterating through 95000 members.

Jimmy Hoffa
  • 5,909
  • 30
  • 53
1

In general, function calls are basic enough to be highly optimized by any interpreter (or compiler). Therefore these do not produce to much blow-up in run time. In fact, if wrap your problem to, say, some fancy iterative solution, you save handling the stack, but instead have to handle some iteration variables, which will not be to hard.

I know, there have been programmers who wondered why their recursive algorithms have been so slow, until someone told them not to pass array entries by value.

You should provide some sample code. In general, you should for other bottlenecks, or find another algorithm.

shuhalo
  • 5,732
  • 12
  • 43
  • 60
1

Just need to run it against a good profiling tool. I've got some stuff I wished only took 4 seconds - works with upwards of a hundred million records in a pass.

tg2
  • 2,190
  • 3
  • 14
  • 21
0

An Array is a reference type not a value type. Therefore you never pass the array. You are actually passing the pointer to the array in memory. So passing the array isn't your issue. Most likely you have an issue with what you do with your array. You need to do what Jamie Keeling said and run it through a profiler or even just debug it and see if you get stuck in some big loops.

Ben Hoffman
  • 8,149
  • 8
  • 44
  • 71
0

Why are you loading them all into an array and doing each method in turn rather than iterating through them as loaded?

If you can obtain them (from whatever input source) deal with them and output them (whether to screen, file our wherever) this will inevitably use less memory and reduce start-up time, at the very least.

If this answer is applicable to your situation, start by changing your methods to deal with enumerations rather than arrays (non-breaking change, since arrays are enumerations), then change your input method to yield return items as loaded rather than loading an entire array.

Jon Hanna
  • 110,372
  • 10
  • 146
  • 251
-1

Sorry for posting an old link (.NET 1.1) but it was contained in VS2010 article, so: Here you can read about method costs. (Initial link)

Then, if you start your code from VS (no matters, even in Release mode) the VS debugger connects to your code and slow it down.

I know that for this advise I will be minused but... The max performance will be achieved with unsafe operations with arrays (yes it's UNSAFE, but when there is performance deal, so...)

And the last - refactor your code to use minimum of methods which working with your arrays. It will improve the performance.

Eugene Cheverda
  • 8,760
  • 2
  • 33
  • 18