[Mono-bugs] [Bug 27796][Nor] Changed - patch to speed to mono_class_vtable

[bugzilla-daemon@rocky.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 lupus@ximian.com.

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

--- shadow/27796	Mon Jul 15 12:17:52 2002
+++ shadow/27796.tmp.7245	Mon Jul 15 13:04:11 2002
@@ -2,13 +2,13 @@
 Product: Mono/Runtime
 Version: unspecified
 OS: Debian Woody
 OS Details: 
 Status: NEW   
 Resolution: 
-Severity: 
+Severity: Unknown
 Priority: Normal
 Component: misc
 AssignedTo: mono-bugs@ximian.com                            
 ReportedBy: vargaz@freemail.hu               
 QAContact: mono-bugs@ximian.com
 TargetMilestone: ---
@@ -27,6 +27,27 @@
 after: 14.3 sec (-15%)
 
 ------- Additional Comments From vargaz@freemail.hu  2002-07-15 12:17 -------
 Created an attachment (id=1996)
 patch
 
+
+------- Additional Comments From lupus@ximian.com  2002-07-15 13:04 -------
+You avoid the lock in the domain, but you need a lock in the class
+with this code: after the conditional check, another thread in another
+domain may have updated class->cached_vtable.
+
++
+/* An optimisation to avoid locking */
++
+if (class->cached_domain == domain)
++
+	return class->cached_vtable;
+
+The speed gain is relevant, so I'd like to do something about this
+bottleneck anyway. For example we could cache the string vtable in the
+domain: a quick patch shows a 3% improvement.
+We can check if we can do something like that for the arrays, though
+the main problem is probably that the lock/unlock operations are way
+too slow and should be optimized: we use the platform layer that
+emulates the win32 critical regions. Using a simple pthread mutex
+could be worthwhile.