Karl Seguin

Can you paste the link to the Travis article please? Thanks!

Personally, I started using your approach some time ago and I have found the same benefits you described (in the use string.format article) and no performance issue at all have been found, so I totally agree with you.

Thanks!

I've been guilty of micro-optimization in the past.  Do you know what I gained from it?  Absolutely nothing.  However, I did lose valuable time that could have been better spent refactoring design issues.  String.Format certainly improves readability, but the performance gain you receive is negligable by removing it.  Like you said, concentrate on the 20% of the application that is doing 80% of the work, which almost always involves a database with indexing and caching techiniques to be tweaked.

Karl,

I obviously overstated my point. I completely agree with you about the optimization 80/20 rule. My point is that (to me, and maybe only to me) that something that we can all agree produces a 4-6x performance loss so the developer can have slightly "prettier" code (again to me it is only slightly prettier) is crazy.

This is one reason why people now need machice with multicore-gigihertz processors do run even the most simple applications with out unreasonable response. Sure we can decide to only apply this knowledge to Missle Systems or other high requirement software but my question is why? Why when MS wrote this function did they write it to be so slow? Because they appear to have an attitude of, if it is too slow buy faster hardware.

I appologise for even bringing this up.

Macrelo:

It's one of the last comments to my blog post here:

http://codebetter.com/blogs/karlseguin/archive/2006/04/10/142602.aspx

I've been using sprinf() and various string class Format() methods for years (I thought everyone did??). I often like to store these format strings out in whatever resource files and/or configuration files (DBs, .config files, etc...) the system I'm developing under supports. This way you can change/translate these strings without code changes. Of course you have to document what each numbered parameter is. This was hard with sprintf() (or those methods inspired by sprintf) since in the format-string you had to use the input variables in the order they were passed in, making it often hard to radically reword the string. .NET made this much easier allowing you to use any parameter in any order as many times as you want by using the index.

Now we all are talking in generalities, but, in general, I've found most developers are really bad at understanding code performance. Often mirco-optimizing (did you invent that term just now?) code that didn't need it and missing huge issues that, on the surface, seem innocent enough.

IMOHO, code maintainability, reliability, and readability are often just as important as performance. It is not just about nice looking code! Developer cycles are expensive, CPU cycles are not. CPUs keep getting faster and cheaper, good developers are not. As long as your code is fast enough to meet (and maybe beat by a small margin) your requirements then I don’t see the point of not using techniques that make better *code*.

I'm a huge fan of code profiling. It was a huge pain in the ass in unmanaged C++, but worth it (the tools were often buggy). I only assume it is much better in higher level languages (I haven't really used it seriously in .NET).

I think a lot of you are maybe taking Karl a little too literally.  Use common sense.  If you have a tight loop running 5 million iterations, don't use string.format!  Optimize it.  On the other hand, if you have a string with 6 parameters and it gets run only a handful of times, it will be 10x more readable by using string.format and the performance is a nonissue.  

I dont think you can ever make a blanket statement about how to code, because inevitably there will be a counter-example.

Travis:

I think it's good that you brought it up. If nothing else, it highlights the need for developers not to blindly use code. Joel calls this "The law of leaky abstraction". Any good developer should be diligent and strive for a deeper understanding than what seems obvious at first. You should *know* that string.Format might performe slow (relatively speaking anyways) and you should have some idea as to *why*, and THEN you can make the educated decision of whether to use it or not.

I strongly believe that. Tools like Reflector for .NET (free) are real enablers when it comes to this type of self-education.

Thanks for sharing you thought Aardvark - completely agree. If anything developer cycles are becoming MORE expensive again (atleast in some circle, and compared to very recent years).

On the surface I don’t see why string concatenation is *that* much faster then string.format. I wonder why that is? I also wonder if string.Format starts beating the performance of the “+” operator on string building with lots of variables since less temporary strings should have to be created and destroyed. I know I’ve seen instances with MFC’s string class’s format where this was true.

Sort of related: Raymond Chen showed some interesting string performance issues (mostly w/ STL & Unicode issues) and optimizations in his series on a Chinese to English translator app he developed. (google for the The Old New Thing blog -- and subscribe -- it’s a favorite). I bring that up since today he commented again on it, although the string issues were posted awhile ago…

By the way, does anyone else hate coding analogies to “missile guidance systems” or “satellites” or whatever thing where “Instruction at 0x98643967 cannot read from 0x0000000” == 2 Billion $ lost or lives lost?

Do we REALLY want every application to be held those standards?  How much would desktop software cost?? Think how this would stifle innovation?

I also wonder how great some of this code really is?

Aardvark:

My boss used to work on Missigle guidance systems...hence why I threw it in there :)

File this under "beating a dead horse":

OK, I broke out DevPartner Studio's profiler (aka TrueTime). After a great call to their support fixing a licensing issue (how it broke, I dunno)...

I wrote an app that used "+" and "format()".

First I built a string with 3 ints seperated by 10 space strings.

Plus = .03ms

Format = 3.42ms

Wow format sucks, right? Well not really...

If I then call format a second time, same formatting, but 3 different int variables. Format = .5ms! If I passed the same 3 int variables in I got .04ms - not sure why that is?

Next I built strings with 23 variables (mixes of ints, longs, doubles, and strings). Values seperated by "\r\n".

Plus = 2ms

Format = .53ms

I think its safe to say the first time you call format is a killer - I'm sure some .NET guru could explain why... after that, however, things aren't so bad - sometime better. Now this is a very synthetic test so YMMV.

Another lunch break down the tubes...

I generally will go with String.format...but testing this in Java gives me a x50 difference between that ugly static method and the pretty String.format:

import java.util.Date;

public class Prueba{

 public static void main(String[] args){

   String a = "9";

   new Date();

   System.out.println((new Date().getTime()));

   System.out.println(String.format("%012d",new Integer(a)));

   System.out.println((new Date()).getTime());

   System.out.println(completezero(a));

   System.out.println((new Date()).getTime());

 }

public static String completezero(String cad)

 {

   String str_complete="";

   String[] temp = cad.split("\\.");

   cad=temp[0];

   if(cad.length()<=12)

   {

     int count_zero=12 - cad.length();

     String str_zero="";

     for(int i=0;i<count_zero;i++)

     {

       str_zero+="0";

     }

     str_complete=str_zero+cad;

   }

   else

   {

     str_complete=cad;

   }

   return str_complete;

 }

}

Also string concatenation like this:

var s = "hello";

var s += " you";

Actually stores two strings in memory:

"hello" and "hello you"

Using a StringBuilder or string.Format only has one string in memory