Restore synchronous TarWriter fast path

[iremyux]

Restores the stack-allocated, span-based synchronous write path removed by  #129282. The adapter-based asynchronous implementation remains unchanged.

Fixes #130041

[azure-pipelines]

Azure Pipelines:
Successfully started running 3 pipeline(s).
13 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[Copilot]

Pull request overview

This PR changes the synchronous TarWriter.WriteEntry(TarEntry) path to avoid going through the async WriteEntryCoreAsync<SyncReadWriteAdapter> pipeline, aiming to eliminate overhead that can show up in microbenchmarks (as referenced by the linked perf regression issue).

Changes:

• Replaces the sync WriteEntry(TarEntry) implementation with a dedicated synchronous WriteEntryInternal that uses stackalloc and direct header-write methods.
• Adds synchronous TarHeader.WriteAs* entry-writing helpers (and shared helpers for seekable/unseekable data streams, data copy, and padding) to mirror the async flow without adapters/state machines.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
src/libraries/System.Formats.Tar/src/System/Formats/Tar/TarWriter.cs	Routes sync WriteEntry(TarEntry) to a new synchronous internal implementation.
src/libraries/System.Formats.Tar/src/System/Formats/Tar/TarHeader.Write.cs	Introduces synchronous header/data writing helpers parallel to existing async implementations.

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated no new comments.

[azure-pipelines]

Azure Pipelines:
Successfully started running 3 pipeline(s).
13 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[alinpahontu2912]

I think it's fine, but I wonder what is better long-term. The perf regression was caused by the stackallocs that can't be used in async contexts so the adapter that was used for deduplication couldn't use them. @rzikm what do you think?

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated no new comments.

Suppressed comments (2)

src/libraries/System.Formats.Tar/src/System/Formats/Tar/TarHeader.Write.cs:279

• In the PAX + unseekable data stream path, _dataOffset is set while writing into tempStream (so it becomes relative to the temp stream, e.g., 512), but it is never updated to the final offset in archiveStream before copying. This makes TarEntry.DataOffset incorrect after TarWriter.WriteEntry when archiveStream is seekable and DataStream.CanSeek == false.

Update _dataOffset based on the current archiveStream.Position (start of the entry header) before copying tempStream into the archive (and consider mirroring the same fix in WriteAsPaxCoreAsync for parity).

                CollectExtendedAttributesFromStandardFieldsIfNeeded();
                extendedAttributesHeader.WriteAsPaxExtendedAttributes(archiveStream, buffer, ExtendedAttributes, isGea: false, globalExtendedAttributesEntryNumber: -1);
                buffer.Clear();

                tempStream.CopyTo(archiveStream);

src/libraries/System.Formats.Tar/src/System/Formats/Tar/TarHeader.Write.cs:796

• WriteEmptyPadding always stackallocs a full 512-byte buffer and clears it, even when the required padding is much smaller. This does extra stack usage and memory clearing work per entry.

Since paddingAfterData is already bounded to <= TarHelpers.RecordSize, stackalloc only the needed length.

                Span<byte> zeros = stackalloc byte[TarHelpers.RecordSize];
                zeros = zeros.Slice(0, paddingAfterData);
                zeros.Clear();

                archiveStream.Write(zeros);
            }

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated no new comments.

Suppressed comments (1)

src/libraries/System.Formats.Tar/src/System/Formats/Tar/TarHeader.Write.cs:797

• WriteEmptyPadding always stackallocs a full 512-byte buffer even though padding is at most 511 bytes (and often much smaller). This adds avoidable stack pressure in a hot path, especially now that the sync fast path also stackallocs a 512-byte header buffer per entry.

Consider stackalloc’ing exactly the required padding length instead.

        private void WriteEmptyPadding(Stream archiveStream)
        {
            int paddingAfterData = TarHelpers.CalculatePadding(_size);
            if (paddingAfterData != 0)
            {
                Debug.Assert(paddingAfterData <= TarHelpers.RecordSize);

                Span<byte> zeros = stackalloc byte[TarHelpers.RecordSize];
                zeros = zeros.Slice(0, paddingAfterData);
                zeros.Clear();

                archiveStream.Write(zeros);
            }