Does "optimize code" option do anything?

Elements Oxygene
1

For the first time, I just compiled my code in “release” mode. That turned on all the projects (exception the web site application) to release mode and they all have the “optimize code” option on. It didn’t seem to make my code faster. My colleague has the same code in C# which we translated from my Pascal so she is doing the same sequence of calls where my code is being slow. Hers runs pretty good. Mine, not so much. We thought maybe it was because mine was Debug and hers was Release, but now I’ve done release to no effect.

Is my really old version of Delphi Prism not doing optimization? Do the new versions do better? I thought I read once where most of the optimization is done at run time on the IL. Any ideas why mine would be slower? Would using local procedure slow things up. C# doesn’t have that, but I thought Oxygene just translated the local procedures into method calls with mangled names.

Any tips for making things faster?

(my code that is slow takes 4 to 6 seconds and hers takes 1 or 2.)

2

What does your code do ?

3

@mtiede: Optimize removes some debug specific things, like nops, which makes it harder to set breakpoints at places. But as far as I know c# emits pretty much the equivalent code as we do. So a few questions: Do you run in the debugger or outside when measuring speed?

Can I see the projects?

4

@john, Well, it does a lot :slight_smile: My code is invoked by my coworker’s Silverlight app. She using dynamic xap loading and MEF to use my pieces/parts inside her application. In total, we probably have 80 projects and maybe 150,000 to 200,000 lines of code (I’m guessing). The particular part where we are seeing some difference is a place that has 6 comboboxes whose values are related hierarchically. Meaning, once I select a value in the first combobox, the value choices in the next box are limited to those related to the first combobox value. And, since the second one is limited, that limits the choices in the third and so on. So if you pop up the 6th combobox, ONLY the valid choices based on the first box’s choice are shown. And it is a little more complicated than that. But that is basically it.

So the part that seems to take long is finding all the allowed values and populating the comboboxes. Normally, our customers have 10s or 100s of choices and we used simple lists of objects to decide the choices.

But a new customer has 2,000 to 3,000 choices for some of the comboboxes. There is not any logical way to cut those down any more. That is just what they have. The code we had to filter the choices took FOREVER when there were thousands of values. We switched to using some hashsets instead of lists. That helped tremendously as a lot of the time was spent iterating lists and doing Contains method calls. The Contains were the real killers, but once using hashsets, the code got simpler (still somewhat complex).

In any event, my coworker wanted to do the same thing I was doing with hashsets. She had similar code and, because of some division of labor and the way we are using MEF, she didn’t want to use my assembly. So we sat down together and went through my code and translated it to C# (cause she doesn’t want to use Pascal). So she should have the same code I have (more or less). We made the same routines doing the same things. The only major difference I can see is that I use a fair number of local procedures and she can’t do that in C# so she made object class methods instead.

But her code to display the comboboxes appears to take half the time mine takes. By that I mean the time it takes to initially load all the comboboxes with saved values and populate all the combobox choices with appropriate values based on those values. And both sets of code are running with the same data, in the same debugger session in the same app.

That is what prompted my question.

@carlo, we aren’t really measuring the speed, just counting seconds until busyindicator starts till it is gone. The difference in time is evident just watching the screen. So it isn’t like we are splitting hairs over performance. For some reason hers is definitely faster. That was why I was looking for some general response like, “Yes, C# is faster” or “C# is faster when doing these types of things…”

We will have to dig deeper into the code and see if we can pin it down, but I was hoping there might be some known cases of things that are bad.

Or you would say, “Oh, that old, old, old, Delphi Prism is SO much slower than our current version that no wonder you are seeing differences”. If that were the case, it would encourage me to be able to take a breath and bring the compiler up to the latest version (but have SO many things to do on this project, it will still take a while before we could consider upgrading).

So any ideas on specific performance tweak kinds of things that I should look out for? Any tips anyplace on the web site?

5

Is this inside the debugger only or outside too?

6

In and out. When I give my xap to the coworker and she runs it, her part is faster than my part although as far as we can see we are doing the same things. Exceptions, that we can think of, are that I have local procedures and she doesn’t. And she may have some lists that she prepares ahead of time so that the code that we have in “common” sees the same structure.

Mostly we are comparing inside the debugger. But she doesn’t have my source to debug with. And the xap that I have given her has been both in Debug mode and Release mode and that didn’t change anything.

7

I know c# emits some special attributes for the debugger that enable optimiztions, but outside the debugger they should act just as fast.