You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We need to assess the work that was done to build up OutputBuilder's specialized string building. I feel like there had been discussion (probably on a PR or two that introduced such changes) about the why the work was done - but I don't recall if there was any hard evidence of actual performance assessment and comparison versus standard StringBuilder functionality. As such, we need to track down such evidence (if it existed) and record the documentation better, such as embedding it in significant <remarks> comment section on the OutputBuilder class itself. If there is no such evidence, we may need to do fresh performance assessment. Basically, if OutputBuilder is not significantly faster or less memory-thrashing (generating a lot less GC or something) then the potential for bugs from it being custom code may not be worth it.
TLDR: Measure to see if OutputBuilder complexity was premature optimization: If problematic or very comparable to standard StringBuilder ops, simplify the code. If good though, document those performance characteristics.
The text was updated successfully, but these errors were encountered:
DavidRieman
changed the title
OutputBuilder duplicates StringBuilder functionality without documenting why
OutputBuilder duplicates StringBuilder bits: simplify or document
Nov 11, 2024
We need to assess the work that was done to build up OutputBuilder's specialized string building. I feel like there had been discussion (probably on a PR or two that introduced such changes) about the why the work was done - but I don't recall if there was any hard evidence of actual performance assessment and comparison versus standard StringBuilder functionality. As such, we need to track down such evidence (if it existed) and record the documentation better, such as embedding it in significant
<remarks>
comment section on the OutputBuilder class itself. If there is no such evidence, we may need to do fresh performance assessment. Basically, if OutputBuilder is not significantly faster or less memory-thrashing (generating a lot less GC or something) then the potential for bugs from it being custom code may not be worth it.TLDR: Measure to see if OutputBuilder complexity was premature optimization: If problematic or very comparable to standard StringBuilder ops, simplify the code. If good though, document those performance characteristics.
The text was updated successfully, but these errors were encountered: