[Mono-devel-list] Patch for System.Timespan

Ben Maurer bmaurer at users.sourceforge.net
Fri Apr 16 19:37:53 EDT 2004


Ok, a few general comments:
      * You have no changelog. As such, I have a very hard time guessing
        what you tried to do. Please include a detailed changelog
        stating the improvements in each class.
      * You are intermingling formatting changes, bug fixes, and
        performance improvements. What I would suggest you do is the
              * Check in all formatting related changes that you want.
              * Attach *ONE* patch per bug. If a bug appears in multiple
                areas, it is OK to attach one patch that fixes the issue
                in each method. In general, there should be one patch
                per bug that would be filed in bugzilla
              * Attach one patch for each optimization.
      * ALL performance improvements should come with benchmarks.

Some more specific ones:
      * Be careful about large arithmetic. For example, you have
        TicksPerXXX as a long each time. However, if some of these were
        ints, the JIT could make more optimizations. Also, some
        operations could be moved out of checked contexts to make them
      * When you use stringbuilder, try to guess at how long the string
        will be -- this avoids reallocs.

I would really encourage you to consider where you place performance
improvements. Frankly, not that many apps use TimeSpan. I have never
seen it be a bottleneck in those that do. Here are a few ideas -- maybe
they can get you started:
      * Try any method in System.Array on a large array of ints (like
        Array.Sort (my_int_array). Try it under the profiler.
      * Buffer.BlockCopy is slower than Array.Copy. It would be
        interesting to take a look at that.
      * Can we implement String.Concat in C#? There is a thread from a
        while back about this. This method would be interesting also as
        a case study for jit optimizations.
      * Many classes have static ctors that do not need them. Also, some
        classes use the static CLASS () {} construct which prevents
        beforefieldinit. It would be nice to do an audit for this. An
        example of the problem is IntPtr, which has a static ctor to
        init a static field to 0 (this is not needed, as it is inited to
        zero by default).
      * Many components of reflection could use some love.
      * There are many places where we could use stackalloc to avoid the
        cost of hitting the GC. Example -- many of the .ToString methods
        -- they use very small buffers. Good case for stackalloc.

Am betting that a 100% improvement in any one of these issues will net
far more benefit than a 3000% improvement in TimeSpan.

I'd be happy to expand on a specific issue if you are interested. And of
course, this list is non-inclusive.

-- Ben

On Fri, 2004-04-16 at 18:57, Andreas Nahr wrote:
> Hi,
> this is a patch that nearly reimplements System.Timespan.
> It contains a LOT of speed improvements (sometimes of a HUGE magnitude
> like 3000%).
> Also fixes some potential bugs in the old version.
> If nobody objects I'll commit it.
> Andreas

More information about the Mono-devel-list mailing list