CODEWITHSUNDEEP
c#arraysperformanceoptimization64-bit
michael
michael

Reputation: 5

64bit method call slow C#

HI i have a 32bit application being ported to 64bit somehow method calls of 64bit is a lot slower than 32bit.

code example

    class huge_class
{
 class subclass0{}
 class subclass1{}
 class subclass2{}
 class subclass3{}
 class subclass4{}
 class subclass5{}
 class subclass6{}
 class subclass7{}
 //so on... say 300

 private object[] GetClassObj(Stopwatch x)
 {
       Console.WriteLine(x.ElapsedMilliseconds.ToString()); //<- the latency can be observed here, the time it takes to execute this line takes a big amount of time
       object[] retObj = new object[300];
       retObj[0] = new subclass0();
       retObj[1] = new subclass1();
       retObj[2] = new subclass2();
       retObj[3] = new subclass3();
       retObj[4] = new subclass4();
       retObj[5] = new subclass5();
       retObj[6] = new subclass6();
            //so on... to 299
 }
}

    Class CallingClass{
  static void Main(string[] args)
    {


        Console.WriteLine("Ready");
        Console.ReadKey();
        huge_class bigClass = new huge_class();
        Console.WriteLine("Init Done");
        Console.ReadKey();
        Stopwatch tmr = Stopwatch.StartNew();
        object[] WholeLottaObj = bigClass.GetClassObj(tmr);
        Console.WriteLine(tmr.ElapsedMilliseconds.ToString());
        Console.WriteLine("Done");
        Console.ReadKey();
}

for some odd reason on 32bit the GetClassObj is entered faster than on its 64bit version what am i doing wrong

Upvotes: 0

Views: 361

Answers (2)

Jon Skeet
Jon Skeet

Reputation: 1500893

This may be due to cache coherency. Don't forget that each reference will be twice as large on a 64-bit machine as it is on a 32-bit machine. That means:

  • Each of your instance objects is going to be bigger, so they'll be spread out further in memory (there's more per-object overhead in x64 anyway, and any reference fields will be twice the size)
  • The array itself will be about twice as big

Now it could easily be that in the 32-bit CLR you were just within one of the fastest caches on your CPU - whereas on the 64-bit CLR you've gone outside it so it's having to swap memory in and out of that cache, either to another cache or to main memory.

That's why x86 is the default for executable projects in VS2010 (and possibly 2008; not sure). This blog post goes into a lot more detail.

Upvotes: 6

pabdulin
pabdulin

Reputation: 35225

Why it should be faster in the first place? 64-bit pointer operations are twice as heavy (in memory terms), so it's natural for 64-bit app to be slower.

Upvotes: 1

Related Questions