[IronPython] Optimized methods and serious performance issues

[Dino Viehland]

If I had to take a guess it would be that we are constantly re-optimizing the method (failing to successfully cache it) - which would be a significant performance loss.

Any chance we could get you to run a debug build w/ the -X:TrackPerformance and -D command line options?

You should then see in the output "DrawSubset #" where # should be small (e.g. 1 or 2) - if it's large then we know the issue, we just need to get a simple repro of it.

Do you know if the direct X classes come to you via a interop assembly?  Or if they're COM objects?  Maybe we have a strange interaction there that is preventing the back patching for one of those.

________________________________________
From: users-bounces at lists.ironpython.com On Behalf Of Jonathan Jacobs
Sent: Thursday, May 25, 2006 8:33 AM
To: IronPython List
Subject: [IronPython] Optimized methods and serious performance issues

(Please disregard any earlier message about this, I think I might have pressed
"Send" accidentally.)

Hi,

I ran across some "interesting" behaviour today.

Short version:
I have a handful of Direct3D.Mesh objects (courtesy of Direct3D.Mesh.Teapot)
which I render using self.meshInstance.DrawSubset(0). I've been experiencing
pretty serious performance issues, so I did a bit of testing and this is what
I came up with:

(The averages are accumulated every call and averaged (and output) every 500
calls, a small value is obviously better, all values are in milliseconds.)

No drawing calls:
running average: 0.0236448413598 ms
running average: 0.0229452898402 ms
running average: 0.0236400825059 ms
running average: 0.0257713352135 ms

No drawing calls, -X:NoOptimize:
running average: 0.0251883756139
running average: 0.0250299057799
running average: 0.0224732115359
running average: 0.0225412631463

self.mesh.DrawSubset(0):
running average: 3.40948918622 ms
running average: 3.45289207504 ms
running average: 3.43480367147 ms
running average: 3.45502784866 ms

self.mesh.DrawSubset(0), -X:NoOptimize:
running average: 0.111673644441 ms
running average: 0.118880928633 ms
running average: 0.134856876975 ms
running average: 0.11670232533 ms

Helper.DrawMesh(self.mesh, 0):
running average: 0.0415348007294 ms
running average: 0.0328241945979 ms
running average: 0.0296612223703 ms
running average: 0.0330559507815 ms

Helper.DrawMesh(self.mesh, 0), -X:NoOptimize:
running average: 0.063753413583 ms
running average: 0.0668509515698 ms
running average: 0.0603922350916 ms
running average: 0.070181197511 ms

Helper.DrawMesh is my own function implemented in C#:
public class Helper {
   public static void DrawMesh(Microsoft.DirectX.Direct3D.Mesh mesh, int id) {
     mesh.DrawSubset(id);
   }
}

I'm interested as to why the self.mesh.DrawSubset call is so disappointingly
slow and why it is sped up by *disabling* method optimization.

Unfortunately, it is laborious for me to separate the useful code from the
not-so-useful code and I'm not sure how to reproduce this outside of DirectX.
I can take some time out to try and cut this down to the bare essentials if
need be.

Regards
--
Jonathan

When you meet a master swordsman,
show him your sword.
When you meet a man who is not a poet,
do not show him your poem.
                 -- Rinzai, ninth century Zen master
_______________________________________________
users mailing list
users at lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com