--- title: Optimizing the WinDbg DML parser | daily.dev description: A performance investigation into a custom WinDbg command window reveals that the real bottleneck was not the author's code but WinDbg's own DML parser,... canonical: https://daily.dev/posts/optimizing-the-windbg-dml-parser-vt5oz7hjd twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: Optimizing the WinDbg DML parser | daily.dev og:description: A performance investigation into a custom WinDbg command window reveals that the real bottleneck was not the author's code but WinDbg's own DML parser,... og:url: https://daily.dev/posts/optimizing-the-windbg-dml-parser-vt5oz7hjd og:image: https://api.daily.dev/og/posts/vt5OZ7hjD.png og:image:alt: Optimizing the WinDbg DML parser og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # Optimizing the WinDbg DML parser **[Kevin Gosse \(minidump.net\)](https://daily.dev/sources/minidump)** · 7 min read · 0 upvotes · 0 comments ## Summary A performance investigation into a custom WinDbg command window reveals that the real bottleneck was not the author's code but WinDbg's own DML parser, specifically StringBuilder's char indexer. Profiling with dotTrace showed 99.8% of CPU time spent in StringBuilder.get_Chars. The root cause is that since .NET 4.0, StringBuilder internally chains smaller buffers as a linked list rather than reallocating a single array, making character access O(n) relative to the chain length and especially expensive near the start of a large buffer. This caused a vicious cycle where WinDbg's output parsing slowed down as more content was appended, eventually freezing the UI. The fix replaces StringBuilder with a custom Queue-based StringBuffer class offering O(1) amortized character access and a trim method, which was submitted and accepted into the official WinDbg release. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### Why is accessing a character in a large StringBuilder so slow in .NET? Since .NET 4.0, StringBuilder no longer reallocates a single growing array like List does; instead it chains multiple smaller char arrays together as a linked list, with new buffers appended at the end. Because of this, indexing a character requires walking the chain from the end until the right segment is found, making character access an O(n) operation relative to the number of chained segments rather than O(1) as with a plain string. _Developers chasing hidden profiler bottlenecks in StringBuilder-heavy code can find similar deep dives on daily.dev._ ### Why does accessing the first character of a StringBuilder cost more than accessing the last character? A StringBuilder instance holds a reference to the previous chained buffer rather than the next one, meaning the reference you hold points to the last segment appended. Accessing the last character is cheap since it's near the reference, but accessing the first character requires traversing the entire chain of buffers, making early-index access dramatically more expensive as the StringBuilder grows, as shown in a benchmark with 10 million characters. _Anyone optimizing text-buffer heavy parsing code can track practical .NET performance fixes like this on daily.dev._ ### How can I avoid StringBuilder's slow character indexing when parsing a continuously appended buffer? Replace StringBuilder with a custom buffer backed by a Queue, where each appended string is enqueued without copying, and character access walks the queue applying an offset rather than traversing a chained linked list. This keeps indexed character access close to O(1) in the common case and avoids the unnecessary string copy StringBuilder.Append performs, which fixed a freezing issue in WinDbg's DML parser when output was appended faster than it could be parsed. _Teams debugging freezing UIs from buffer parsing can compare custom data structure fixes like this via daily.dev._ ## Similar posts on daily.dev - [C\# Source Generator Performance: Measuring and Optimizing Build-Time Impact](https://daily.dev/posts/c-source-generator-performance-measuring-and-optimizing-build-time-impact-ukrkbo5rf) · We Are .NET · 0 upvotes · 0 comments - [Losing 1½ Million Lines of Go](https://daily.dev/posts/losing-1-million-lines-of-go-urqxvaqw6) · Hacker News · 20 upvotes · 0 comments --- Tags: [#performance](https://daily.dev/tags/performance), [#.net](https://daily.dev/tags/.net), [#c#](https://daily.dev/tags/c#) [View this post on daily.dev](https://daily.dev/posts/optimizing-the-windbg-dml-parser-vt5oz7hjd) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"Optimizing the WinDbg DML parser","url":"https://daily.dev/posts/optimizing-the-windbg-dml-parser-vt5oz7hjd","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/optimizing-the-windbg-dml-parser-vt5oz7hjd"},"datePublished":"2026-10-04T13:06:23.676Z","dateModified":"2026-10-04T13:13:42.683Z","description":"A performance investigation into a custom WinDbg command window reveals that the real bottleneck was not the author's code but WinDbg's own DML parser,...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/bcc9cc59ad2f1874a555a40705992878?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/bcc9cc59ad2f1874a555a40705992878?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"Kevin Gosse (minidump.net)","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Kevin Gosse (minidump.net)","logo":"https://media.daily.dev/image/upload/s--8KHn1aFB--/f_auto,q_auto/v1791119046/logos/minidump?_a=BAMAMicg0","url":"https://daily.dev/sources/minidump"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/optimizing-the-windbg-dml-parser-vt5oz7hjd","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":0},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"performance,.net,c#","timeRequired":"PT7M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Kevin Gosse (minidump.net)","item":"https://daily.dev/sources/minidump"},{"@type":"ListItem","position":3,"name":"Optimizing the WinDbg DML parser"}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/optimizing-the-windbg-dml-parser-vt5oz7hjd#faq","mainEntity":[{"@type":"Question","name":"Why is accessing a character in a large StringBuilder so slow in .NET?","acceptedAnswer":{"@type":"Answer","text":"Since .NET 4.0, StringBuilder no longer reallocates a single growing array like List does; instead it chains multiple smaller char arrays together as a linked list, with new buffers appended at the end. Because of this, indexing a character requires walking the chain from the end until the right segment is found, making character access an O(n) operation relative to the number of chained segments rather than O(1) as with a plain string. Developers chasing hidden profiler bottlenecks in StringBuilder-heavy code can find similar deep dives on daily.dev."}},{"@type":"Question","name":"Why does accessing the first character of a StringBuilder cost more than accessing the last character?","acceptedAnswer":{"@type":"Answer","text":"A StringBuilder instance holds a reference to the previous chained buffer rather than the next one, meaning the reference you hold points to the last segment appended. Accessing the last character is cheap since it's near the reference, but accessing the first character requires traversing the entire chain of buffers, making early-index access dramatically more expensive as the StringBuilder grows, as shown in a benchmark with 10 million characters. Anyone optimizing text-buffer heavy parsing code can track practical .NET performance fixes like this on daily.dev."}},{"@type":"Question","name":"How can I avoid StringBuilder's slow character indexing when parsing a continuously appended buffer?","acceptedAnswer":{"@type":"Answer","text":"Replace StringBuilder with a custom buffer backed by a Queue, where each appended string is enqueued without copying, and character access walks the queue applying an offset rather than traversing a chained linked list. This keeps indexed character access close to O(1) in the common case and avoids the unnecessary string copy StringBuilder.Append performs, which fixed a freezing issue in WinDbg's DML parser when output was appended faster than it could be parsed. Teams debugging freezing UIs from buffer parsing can compare custom data structure fixes like this via daily.dev."}}]} ```