[Mono-bugs] [Bug 76399][Maj] Changed - System.IO.StreamReader.ReadLine is incredibly inefficient

[bugzilla-daemon at 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 at users.sf.net.

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

--- shadow/76399	2005-10-10 16:14:37.000000000 -0400
+++ shadow/76399.tmp.15750	2005-10-10 17:52:35.000000000 -0400
@@ -1,28 +1,38 @@
 Bug#: 76399
 Product: Mono: Class Libraries
 Version: 1.1
-OS: 
+OS: unknown
 OS Details: 
 Status: NEW   
 Resolution: 
-Severity: 
+Severity: Unknown
 Priority: Major
-Component: System
+Component: CORLIB
 AssignedTo: gonzalo at ximian.com                            
 ReportedBy: trow at ximian.com               
 QAContact: mono-bugs at ximian.com
 TargetMilestone: ---
 URL: 
-Cc: 
 Summary: System.IO.StreamReader.ReadLine is incredibly inefficient
 
 Because it creates a new StringBuilder for each line and assembles the
 string one character at a time, just running this:
 
   StreamReader reader;
   reader = new StreamReader ("a 1.7Mb text file");
 
   string line;
   while ((line = reader.ReadLine ()) != null) { }
 
 Causes 10.7Mb of strings to be allocated.
+
+------- Additional Comments From bmaurer at users.sf.net  2005-10-10 17:52 -------
+We should attempt to find the \n within the current char [] buffer,
+and if it is there, use the data directly from the buffer. There is
+one risk here: the Read methods are virtual. In theory, somebody could
+override them. So we might be making a breaking change.
+
+One other option we have: we can first allocate an 80 char string on
+the stack (with stackalloc). If the string is less than that length,
+then we never need to create the string builder. sp and lupus will not
+like this though :-).