הערה
הגישה לדף זה מחייבת הרשאה. באפשרותך לנסות להיכנס או לשנות מדריכי כתובות.
הגישה לדף זה מחייבת הרשאה. באפשרותך לנסות לשנות מדריכי כתובות.
Question
Thursday, October 26, 2006 8:02 AM
My question:
VB 2005 now offers different methods to write/read a file, such as the File.WriteAllText, the My.Computer.FileSystem.WriteAllText and the StreamWriter.
Can anybody explain when is it better to use which method, which one is more efficient in term of memory/processor use and performance time?
Thanks!!
All replies (7)
Thursday, October 26, 2006 9:18 AM ✅Answered
there isnt much difference, underneath the My.Computer.FileSystem.WriteAllText, its using the streamwriter/filestream to write to the file. It's just a method/function developed especially for VB2005.
Older versions would require the use of StreamWriter to write to the stream since the My namespace does not exist in earlier versions
Thursday, October 26, 2006 9:39 AM ✅Answered
File.WriteAllText() and My.Computer.FileSystem.WriteAllText() are only shortcuts, they still use StreamWriter internally.
If all you want to do is quickly write a small piece of text to a file, use WriteAllText(), but if you want more control on how the file is written, such as when to open and close the file, use StreamWriter.
When you have a large amount of text to write, using WriteAllText() is generally not a good idea because you'll be creating large temporary strings. You can write small amounts at a time in append mode, but you'll still get the unecessary overhead of opening/closing the file repeatedly.
The .NET Framework is designed to be powerful, In my opnion it makes perfect sense to put a "WriteAllText" method, in "File" class.
Thursday, October 26, 2006 9:54 AM
yup yup yup I would agree to that and is what I would have stated also.
however If I may make one suggestion in regards to this:
When you have a large amount of text to write, using WriteAllText() is generally not a good idea because you'll be creating large temporary strings
true so in this case, you are better, in general anyway, to use a StringBuilder to append strings then finally call .ToString() on the object when time comes to giving the WriteAllText the string to write to file
Thursday, October 26, 2006 12:13 PM
Thanks, guys! Your information has been quite helpful and enlighting! 
Friday, March 16, 2007 5:39 PM
| ahmedilyas wrote: | |
|
I somewhat disagree - if I have 200MB+ text to write (comes from xml) I would not want to save that into StringBuilder (in memory).
I would rather write it text file line by line (StreamWriter or WriteAllText {overhead of opening & closing the file 200K times}) - agreeing with RyanTsai's comment
As far as I know - Internet Explorer takes about 2GB or more memory to open 200MB xml file {dont try this at home} - so I am not convinced that StringBuilder utilizes large amounts of data more efficiently.
"MS all the way" - well it's good to see eternal optimism
Tuesday, May 22, 2007 1:56 PM
Digging up this old thread since it comes up in MSDN help searches so well.
Another thing to be aware of if you're using WriteAllText is the Byte Order Mark. If you don't use the overload that specifies the encoding type to use, the default is to use UTF-8 encoding which will add the BOM "" to the beginning of your file. If another program is expecting an ASCII encoded file this will probably cause them to either reject the file or act strangely. Also, you won't see the BOM if you open the file in Notepad or Wordpad since they automatically process it out when they read the file. This might cause you to think that your file is 'OK' when it isn't. The best thing to do if you're going to use WriteAllText is to always use the overload where you specify the encoding type.
Thursday, August 26, 2010 4:21 PM
Another thing to be aware of if you're using WriteAllText is the Byte Order Mark. If you don't use the overload that specifies the encoding type to use, the default is to use UTF-8 encoding which will add the BOM " " to the beginning of your file.
That's not true. You can verify in Reflector that the default encoding is UTF8NoBoM.