[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-07 03:49:56.000000000 -0400
+++ shadow/59537.tmp.2554	2004-06-08 05:16:38.000000000 -0400
@@ -250,6 +250,23 @@
 It usually does a good , nevertheless it may has it's own bugs. 
 I think that our code is also using string pool to avoid the new
 string  allocations (which may explain our differences in the overall
 results).
 10X for your time , you can close this bug. 
 
+
+------- Additional Comments From mordechait@mainsoft.com  2004-06-08 05:16 -------
+I thougt about it more... your code and my code use the same
+number of strings allocations. So the issue is not allocation time.
+You claimed that the method re-written because you got "pretty big
+perf boost". 
+My conclusion is : the only thing that could boost you is the fact you
+calculated the hash code by yourself (and not using
+String::GetHashCode() like I suggested).
+(another thing that can slow you down is calling an additional method.
+but the overhead it takes is only 0.1ms so it is insignificant).
+That's wierd. something must be rotten in GetHashCode() , after all,
+it should do the same job.
+If this is the situation I think that solving String::GetHashCode()
+problem will give you "pretty big pref boost". I know Sun and Micosoft
+invested some native code to make this hash method rock. (in fact they
+invested alot in the class String).