[Mono-bugs] [Bug 59537][Nor] Changed - improve NameTable performance

[bugzilla-daemon@bugzilla.ximian.com]

Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.

Changed by bmaurer@users.sf.net.

http://bugzilla.ximian.com/show_bug.cgi?id=59537

--- shadow/59537	2004-06-06 10:52:50.000000000 -0400
+++ shadow/59537.tmp.27691	2004-06-06 11:00:20.000000000 -0400
@@ -195,6 +195,41 @@
 4810000
 Total time spent compiling 604 methods (sec): 0.1
 Slowest method to compile (sec): 0.01: System.DateTime::GetNow()
 
 Total memory allocated: 6880 KB
 
+
+------- Additional Comments From bmaurer@users.sf.net  2004-06-06 11:00 -------
+Hello,
+
+Can you try the old version of NameTable with your examples? If you
+look at the revisions of NameTable you will see one that is
+implemented in the way you suggested. When I made the changes, I got a
+pretty big perf boost.
+
+I would like to address some of your specific comments here:
+
+`I think using unsafe code in Add method is not the ideal solution.
+In my opinion the ideal solution is to write String::GetHashCode()
+method optimized , preferably with unmanaged code. (I havn't checked
+but it may be optimized already...)'
+
+It is written in unmanaged code today. However, it turns out that a
+managed version written with unsafe code is MUCH faster.
+
+`IBuySpy application clearly showed that the the most useful method is
+the one which accept a String (I used JProfiler to see that).
+I think I saved the session and the graphs if you are really
+interested...'
+
+Not true at all. If you only need to do strings, try String.Intern.
+The intended use of NameTable is with char []'s.
+
+`(what will happent if
+someone will overload the Add with StringBuilder parameter?)'
+We would implement another version of the hashcode thingy.
+
+`I think we should pay the performance
+"fee" and perform a delegation to one ImplMethod'
+
+No, this will result in extra allocations.