[Mono-devel-list] Patch for System.Timespan
Ben Maurer
bmaurer at users.sourceforge.net
Fri Apr 16 19:37:53 EDT 2004
Hello,
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
following:
* 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
faster.
* 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