[Mono-bugs] [Bug 69999][Wis] Changed - BigInteger: Optimizations suggestions

[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 sebastien@ximian.com.

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

--- shadow/69999	2004-11-29 12:31:42.000000000 -0500
+++ shadow/69999.tmp.20174	2004-11-30 16:16:45.000000000 -0500
@@ -1,22 +1,41 @@
 Bug#: 69999
 Product: Mono: Class Libraries
 Version: unspecified
 OS: All
 OS Details: 
-Status: NEW   
+Status: ASSIGNED   
 Resolution: 
 Severity: Unknown
 Priority: Wishlist
 Component: Mono.Security
 AssignedTo: sebastien@ximian.com                            
 ReportedBy: pieter@mentalis.org               
 QAContact: mono-bugs@ximian.com
 TargetMilestone: ---
 URL: 
 Cc: 
-Summary: BigInteger: ModulusRing.OddPow doing double work?
+Summary: BigInteger: Optimizations suggestions
 
 The final Montgomery.Reduce in the ModulusRing.OddPow method seems 
 unnecessary to me. As far as I can see, resultNum will always be reduced 
 before it leaves the loop.
 Is there a reason that there's a reduce after the for loop?
+
+------- Additional Comments From sebastien@ximian.com  2004-11-30 16:16 -------
+*** ModulusRing.OddPow doing double work ? ***
+
+A quick test with removing the last *outside* the loop Reduce makes
+several unit tests fails (but that doesn't means it's required - just
+that it need more investigations ;-). 
+
+However the last Square/Reduce *in* the loop can ALWAYS be avoided
+when processing the last bit (pos == totalBits - 1) because tempNum
+won't be used afterward. The same trick can be done for EvenPow.
+
+I'll let this bug open (and assigned) until:
+- I've the time to add more tests to BigInteger (and hopefully
+fix/optimize some cases); and / or
+- a better setup to time the class performance. 
+
+In the mean time feel free to add any performance suggestions to it (I
+renamed the bug to allow this). I appreciate them :-). Thanks.