Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>It's likely to be IO dominated ( writing the output to the console or a file will be the slowest part ), so probably won't benefit from a high degree of optimisation. Simply removing obvious pessimisations should suffice.</p> <p>As a general rule, don't create temporary objects. Each iteration of your loop creates a temporary string, coping the entire previous string in <code>a</code> and the value of the string in <code>b</code>, so has to do up to 20000 times the length of <code>b</code> operations each time through the loop. Even so, that's only 3 billion bytes to copy, and so should complete in less than a second on a modern machine ( assuming the runtime uses the right operations for the target hardware ). Dumping 160,008 characters to the console may well take longer.</p> <p>One technique is to use a builder or buffer to create fewer temporary objects, instead creating a long string in memory using a <code>StringBuilder</code> then copying that to a string, then outputting that string.</p> <p>However, you can go one stage further and achieve the same functionality by writing the output directly, rather than creating any temporary strings or buffers, using <code>Console.Write</code> in the loop instead. That will remove two of copying operations ( the string b is copied to the buffer then the buffer is copied to a string object then the string's data to the output buffer; the final copy operation is the one internal to Console.Write so is not avoidable in C# ), but require more operating system calls, so may or may not be faster. </p> <p>Another common optimisation is to unroll the loop. So instead of having a loop which has one line which writes one " World! " and is looped 20,000 times, you can have (say) five lines which write one " World! " each and loop them 4,000 times. That's normally only worth doing in itself if the cost of incrementing and testing the loop variable is high compared to what you're doing in the loop, but it can lead to other optimisations. </p> <p>Having partially unrolled the loop, you can combine the code in the loop and write five or ten " World! "s with one call to <code>Console.Write</code>, which should save some time in that you're only making one fifth the number of system calls.</p> <hr> <p>Writing to console, in cmd window, it appears limited by speed of console window:</p> <p>( times in seconds for 100 runs ) </p> <pre><code> 724.5312500 - concat 53.2187500 - direct 30.3906250 - direct writing b x10 30.3750000 - direct writing b x100 30.3750000 - builder 30.3750000 - builder writing b x100 </code></pre> <p>writing to file, the times for the different techniques differ:</p> <pre><code> 205.0000000 - concat 9.7031250 - direct 1.0781250 - direct writing b x10 0.5000000 - builder 0.4843750 - direct writing b x100 0.4531250 - builder writing b x100 </code></pre> <p>From this it's possible to draw two conclusions: </p> <p>Most of the improvements don't matter if you're writing to the console in a cmd.exe window. You do have to profile the system as a whole, and (unless you're trying to reduce the energy use of the CPU ) there's no point optimising one component beyond the capbilities of the rest of the system.</p> <p>Although apparently doing more work - copying the data more and calling the same number of functions, the StringBuilder approach is faster. This implies that there's quite a high overhead in each call to Console.Write, compared with the equivalent in non-managed languages.</p> <p>writing to file, using gcc C99 on Win XP:</p> <pre><code> 0.375 - direct ( fputs ( b, stdout ) 20000 times ) 0.171 - direct unrolled ( fputs ( b x 100, stdout ) 200 times ) 0.171 - copy to b to a buffer 20000 times then puts once </code></pre> <p>The lower cost of the system call in C allows it to get towards being IO bound, rather than limited by the .net runtime boundaries. So when optimizing .net, managed/unmanaged boundaries become important.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload