eiffelroom - UTF-8 Unicode .NET - Comments

There is a overhead involved

patrickr — Mon, 21 May 2007 00:49:07 -0700

There is a overhead involved but most of the time I still got a pretty good indication where I can start to optimize. It's also possible to just selectively trace certain functions only, which reduces the profiling overhead a lot. If you look at the data in kcachegrind or a similar tool there is also more data available than this single graph can show you. E.g. the number of calls are also listed.

No guarentees

colin-adams — Sat, 19 May 2007 23:51:00 -0700

Because you have no guarantees that the overhead is distributed proportionally to the true execution time of the routines involved. Instead, I would expect the overhead to be distributed according to the frequency of the routine calls, although I don't know this for sure.

So I am interested in the proportion of the time spent in UTF-8 routines, not the frequency at which they are called. I don't care much about the latter as long as the overall time spent is small (because if it is small, there is no point in trying to optimize it). Colin Adams

Overhead

peter_gummer — Sat, 19 May 2007 20:08:13 -0700

Hey Colin, I don't understand why profiler overhead invalidates the percentages.

I'm no expert on using profilers, but my experience with NProf 0.9 was that it increased the total run time from about twenty seconds up to about four minutes: a factor of 10 or so. In a normal twenty-second run outside the profiler, there's (1) a delay of about five seconds while our VB application loads; then (2) I click a few buttons, which takes a couple of seconds; then (3) there's an eight- or nine-second delay which (as far as I can figure out) is the .NET jitter just-in-time compiling a huge amount of Eiffel code (our stuff + base library routines + Gobo geyacc and gelex stuff); followed by (4) a second or so of parsing and then (5) a second or so of populating some GUI controls. Therefore, the twenty seconds total run time consists of only about five or six seconds of time that's likely to be affected by profiler overhead; which would be an overhead factor of 80 or so.

In other words, I think the NProf overhead factor is somewhere between 10 and 100.

Despite this, I found the percentages reported by NProf to be very useful. They showed me two places where I should optimise, and doing so has cut steps (4) and (5) from about three seconds down to about one second. Without NProf's guidance, I might have attempted the SYSTEM_STRING_FACTORY optimisation, but there's no way I would figured out the other one.

(NProf hasn't helped me with the big delay at step (3). This delay is constant, regardless of what data file I feed to our application, and seems to be due to the .NET jitter infrastructure, so I don't think a profiler is going to help me there.)

Overhead

colin-adams — Sat, 19 May 2007 12:15:45 -0700

OK. I shall remember that. But I don't know if it shows anything meaningful.

I'd rather see the total accumulated time (as a %) of all routines in UC_UTF8_STRING.

But it is only meaningful if the overhead of profiling is low. Last time I use the ES profiler, it lengthened runtimes by a factor of about 100, which meant it was useless.

Do you have the elapsed times with and without profiling for comparison? Colin Adams

It's generated by running

patrickr — Sat, 19 May 2007 11:11:19 -0700

It's generated by running the app with the callgrind tool from valgrind (http://valgrind.org/) and then back translating the c names into eiffel names by using http://eiffelroom.com/tool/valgrind_converter and then I used kcachegrind (http://kcachegrind.sourceforge.net/cgi-bin/show.cgi).

Pretty diagram

colin-adams — Sat, 19 May 2007 04:44:33 -0700

That's a really pretty diagram Patrick.

How do you produce it? Colin Adams

Gobo xml parser

patrickr — Sat, 19 May 2007 03:04:33 -0700

Here's a profile run of the gobo xml parser. The percentages are relative to XM_EIFFEL_PARSER_SKELETON::parse_from_string

Apply Application Optimizations

peter_gummer — Thu, 17 May 2007 18:18:27 -0700

Apply Application Optimizations is a new option in EiffelStudio 6.0. I don't see it in 5.7. When we move to 6.0 I'll be sure to try it; I don't think any of our VB classes inherit from our Eiffel classes.

Thanks for the advice, Paul.

UC_UTF8_STRING performance

colin-adams — Thu, 17 May 2007 09:44:59 -0700

This was very interesting Peter. I have long suspected that the poor performance of the Gobo Eiffel XML parser was down to the UTF-8 implementation, and this seems to give corroboration of that conjecture. Colin Adams

Squeezing more performance from Eiffel for .NET

paulbates — Thu, 17 May 2007 09:30:35 -0700

We've all been pretty busy around here of late so there is a whole list of articles I need to get to. One of them deals with performance optimization in .NET.

There are two additional things you can do to boost performance of your .NET application. First inherit a .NET type (SYSTEM_OBJECT will probably be the most used) where multiple inheritance is not required. This will create an Eiffel single type. The implementation of single types do not have an interface and implementation type and so the CLR is able to optimized the jitted code. The CLR/JIT does not heavily optimize calls through interfaces, if at all!

The second thing is to set the Apply Application Optimizations target configuration option to True. This should only be used for end-point libraries. The optimization only marks end-point classes as frozen so the jitter can optimize the virtually dispatched calls. There is no rule to say that the Apply Application Optimizations option can only be used on end-point applications/libraries. If you want to enable it for your precompiled libraries then feel free. The side effect is that all the end-point classes are marked frozen and so cannot be extended. Fortunately the Apply Application Optimizations option can be applied at a target, cluster and class level for fine grained control.

In future versions of Eiffel for .NET there will be no need to perform the first step because it will be part of the application optimization options.