[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 mordechait@mainsoft.com.

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

--- shadow/59537	2004-06-03 07:44:44.000000000 -0400
+++ shadow/59537.tmp.27232	2004-06-06 10:12:08.000000000 -0400
@@ -67,6 +67,29 @@
 allocation. This ended up killing performance.
 
 One thing we can do is to use unsafe code to avoid some of the
 overhead of Array Bounds Checking.
 
 
+
+------- Additional Comments From mordechait@mainsoft.com  2004-06-06 10:12 -------
+The code example with which I checked the performance is not a trivial
+one (it is called IBuySpy (check out www.ibuyspy.com) and it is
+Microsoft's answer for PetStore).
+
+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...)
+
+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...
+
+I also think that beside the performance issue we also have the OOP
+concern. The original design is error prone (what will happent if
+someone will overload the Add with StringBuilder parameter?) . In
+order to make the code resilient I think we should pay the performance
+"fee" and perform a delegation to one ImplMethod. Afterall , the real
+performance problems are not here, they are in System.Data (this is
+why I rated the issue NORMAL and not CRITICAL)
+