Trim logs once to 75% of a 3 MB cap and batch stdout capture - #216
Merged
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
A CPU sample of RocketSim on macOS showed about 10% of all samples on the
com.swiftlee.diagnostics.loggerqueue, almost all of it inLogsWriter.trimIfNecessary. The log file was pinned at the 2 MB cap:SYSTEM:records could never be trimmed, so trimming evicted the newest structured history instead.Changes
LogsTrimmer: replaced with one linear byte pass (memchr/memmem, no regex and noStringsplit). It drops everything that isn't aDIAGNOSTICS_JSONrecord (legacy HTML, blank lines, continuation text), drops empty system records, and keeps the newest records within a byte budget. If the oldest kept record isn't asessionStart, the nearest earliersessionStartis kept too, so events keep their session metadata in reports.LogsWriter: when an append pushes the file overmaximumLogSize, it trims once, down to 75% of the cap, with one atomic write. Appends that stay under the cap never trim.write(_:)accepts a batch of records and returns aWriteOutcome. Trim failures stay nonfatal and are reported throughos_log.DiagnosticsLogger: the cap goes from 2 MB to 3 MB (trim target 2.25 MB). Empty and whitespace-only stdout/stderr lines are skipped, and each captured pipe chunk is written with a single append. The writer and the output replay can be injected for tests.setup().Tests
New Swift Testing suites, with no sleeps or polling:
LogsTrimmerTests: legacy and blank lines dropped, empty system records dropped, newest records kept in order,sessionStartpreservation, marker lookalikes inside messages, returnsnilwhen nothing can be trimmed, oversized record.LogsWriterTrimmingTests: a production-shaped fixture trims to the target in one write and keeps an ordered suffix of the newest records. After that trim, every append under the cap returns.appendeduntil the next crossing. Also covers batched appends and parsing the trimmed file into sessions with metadata.DiagnosticsLoggerStandardOutputTests: blank lines produce no records, and a multi-line chunk results in exactly one write.All existing XCTest tests pass: 53 XCTest and 16 Swift Testing tests in total.