fix(FastLogger): enable SplitterChannel #5379

[aleks-f]

Makes the FastLogger type=fast logging path production-ready and removes the SplitterChannel limitation. Rebased on main.

Fixes #5379. Also fixes #5381 (Debug d postfix for executables).

Feature

• Enable SplitterChannel as a FastLogger sink; a splitter maps to multiple Quill sinks.
• Per-source routing: each Poco::Logger source gets its own Quill logger, preserving %s / %(logger).
• Make type=fast usable from Poco::Logger by installing the FastLogger as the logger's channel, preserving source names.
• Honor per-logger levels under type=fast.
• PatternFormatter translation: local-time timestamps by default, honor times / %L, keep timestamp separators.
• Flush per-source bridge loggers, bound their count, and route EventChannel-only configs to a null sink.

Correctness and robustness fixes

• Reconfigure routing: setChannel() releases the prior per-source Quill loggers, so a reconfigure rebinds each source to the new sinks instead of reusing stale ones.
• setPattern() / addFileSink() throw NotImplementedException instead of a silent no-op (addFileSink no longer truncates the target file as a side effect); sinks and pattern come from the Channel passed to setChannel().
• _level and the opaque Quill/source-state pointers are atomic for the lock-free reads on the logging path.
• Mirror the Poco::Logger level only when one is configured; otherwise leave hierarchy inheritance intact.
• Skip a malformed numeric quill.* backend option with a warning instead of throwing from the first log call.

Build (#5381)

• Give Poco's own executables the Debug d postfix via a poco_add_executable macro instead of overriding the built-in add_executable. The global override leaked into projects that build Poco through add_subdirectory and captured CMP0155, disabling C++20 module scanning for the executables it created. The now-redundant per-target DEBUG_POSTFIX lines are removed.
• Remove the unused build.ps1 dev script.

Tests

• Per-source routing, reconfigure routing, multiple sources, unsupported setters, concurrent logging, per-logger level across a splitter, malformed options, and the EventChannel-only null-sink path.

Also includes minor Data/SQLite test and documentation additions (#5370).

[Copilot]

Pull request overview

This PR updates FastLogger so it can correctly adapt a SplitterChannel into multiple Quill sinks (instead of falling back to a single console sink), and adds coverage for the new behavior. It also introduces a standalone Windows PowerShell build/test helper script.

Changes:

• Add SplitterChannel::getChannel() accessor and update FastLogger sink collection to recursively enumerate splitter children (plus sink de-duplication).
• Add/extend Foundation tests to verify splitter fan-out and graceful skipping of unsupported EventChannel inside a splitter.
• Add build.ps1 to configure/build/test Poco on Windows via CMake and Visual Studio toolchain setup.

Reviewed changes

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

Show a summary per file

File	Description
Foundation/testsuite/src/FastLoggerChannelsTest.h	Declares a new test for EventChannel behavior under FastLogger.
Foundation/testsuite/src/FastLoggerChannelsTest.cpp	Expands splitter coverage and adds an EventChannel-skipping test.
Foundation/src/SplitterChannel.cpp	Implements getChannel(int) to enable safe child enumeration.
Foundation/src/FastLogger.cpp	Recurses into SplitterChannel children, skips EventChannel, and de-duplicates sinks.
Foundation/include/Poco/SplitterChannel.h	Exposes getChannel(int) in the public API.
build.ps1	Adds a Windows standalone build/test script for Poco via CMake.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[matejk]

@aleks-f, I reviewed the code and made come corrections. Can you please verify that my changes are sane? Then I'd merge to main.

[aleks-f]

@aleks-f, I reviewed the code and made come corrections. Can you please verify that my changes are sane? Then I'd merge to main.

the main reason for fast logger was speedup, which was partially because of pattern formatting. if we completely disregard quill pattern formatting, part of the speedup goes away and fast logger loses at least a part its original purpose.

To see what we currently have in this PR, we need benchmark results on linux and windows to tell whether fast logger as it is now actually brings any benefit.

Also, FastLogger must remain transparent - adding .type = fast to ordinary Poco logger properties must work

[matejk]

Benchmark results comparing FastLogger with the regular Logger (Linux, OrbStack 18-core VM, null sinks, same pattern). Numbers are cost per logging call; CPU is time on the logging thread. Cases are in Benchmark/src/LoggerBench.cpp.

Single sink, typical pattern: regular Logger 472 ns; FastLogger direct API 8.4 ns CPU (87 ns wall); FastLogger through Poco::Logger (type=fast) 437 ns.

SplitterChannel fan-out, cost per call by sink count:

sinks	regular Logger	FastLogger direct (CPU)	FastLogger via Poco::Logger
1	731 ns	14.0 ns	455 ns
2	838 ns	13.6 ns	447 ns
4	966 ns	13.5 ns	450 ns
8	1302 ns	13.4 ns	446 ns

Regular logging cost grows linearly with the sink count, because it formats once per child on the logging thread. FastLogger cost is independent of the sink count: the logging thread enqueues once and the backend renders and fans out. The direct API is 52x faster at one sink and 97x at eight; through Poco::Logger it is 1.6x at one sink and 2.9x at eight.

With a single sink the Poco::Logger path is not faster than the regular Logger, because Poco::Logger builds the full Message (timestamp, thread id, source) synchronously before the channel, and that cost is not deferred to Quill. The direct API avoids it. For multiple sinks the Poco::Logger path still gains, since the regular path pays per-sink formatting and FastLogger does not.

[matejk]

Verified performance.