Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>For your <strong>separate question</strong>, Win32 has a <strong><a href="http://msdn.microsoft.com/en-us/library/aa365749(VS.85).aspx" rel="nofollow noreferrer">WriteFileGather</a></strong> function, which could efficiently write a list of (interned) strings to disk - but it would make a notable difference only when being called asynchronously, as the disk write will overshadow all but extremely large concatenations. </p> <p>For your <strong>main question</strong>: unless you are reaching megabytes of script, or tens of thousands of scripts, don't worry. </p> <p>You can expect StringBuilder to double the allocation size on each reallocation. That would mean growing a buffer from 256 bytes to 1MB is just 12 reallocations - quite good, given that your initial estimate was 3 orders of magnitude off the target.</p> <p>Purely as an exercise, some estimates: building a buffer of 1MB will sweep roughly 3 MB memory (1MB source, 1MB target, 1MB due to copying during realloation). </p> <p>A linked list implementation will sweep about 2MB, (and that's ignoring the 8 byte / object overhead per string reference). So you are saving 1 MB memory reads/writes, compared to a typical memory bandwidth of 10Gbit/s and 1MB L2 cache.)</p> <p>Yes, a list implementation is potentially faster, and the difference would matter if your buffers are an order of magnitude larger. </p> <p>For the much more common case of small strings, the algorithmic gain is negligible, and easily offset by other factors: the StringBuilder code is likely in the code cache already, and a viable target for microoptimizations. Also, using a string internally means no copy at all if the final string fits the initial buffer.</p> <p>Using a linked list will also bring down the reallocation problem from O(number of characters) to O(number of segments) - your list of string references faces the same problem as a string of characters!</p> <p><hr> So, IMO the implementation of StringBuilder is the right choice, optimized for the common case, and degrades mostly for unexpectedly large target buffers. I'd expect a list implementation to degrade for very many small segments first, which is actually the extreme kind of scenario StringBuilder is trying to optimize for. </p> <p>Still, it would be interesting to see a comparison of the two ideas, and when the list starts to be faster.</p>
    singulars
    1. This table or related slice is empty.
    1. POString concatenation in C# with interned strings
      singulars
      1. PTQuestion
    1. PTAnswer
    1. This table or related slice is empty.
    1. USpeterchen
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POString concatenation in C# with interned strings
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTAcceptedByOriginator
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. COThank you for answering both questions. That is an excellent point about string lengths. Longer+interned strings would have a significantly higher advantage over short+interned due to the linked list overhead. The problem I've laid out uses lots of short strings. Perhaps an optimization to StringBuilder would be to do a string[] internally for strings of length longer than X but do string.Concat for strings less than X. These seems to be getting to the likes of a Rope needed for text editors.
      singulars
      1. PO
      1. USColin Burnett
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

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