diegomrsantos opened a new issue, #4179: URL: https://github.com/apache/iggy/issues/4179
Part of #4174. **Affected areas:** Iggy server, Performance. Disk poll task creation and completion delivery transfer owned state through a detached future and a boxed result. Measure whether their current copy or allocation costs justify a focused representation change. This is a lower priority investigation because the available profiles predate reductions in the state carried through this path. **Existing evidence** Historical profiling compared baseline `dc2b382097ed7fb6cfeb8a31fed0fbc74af4433e` with candidate `a699ff91c6b9126502ea112ac676d96d8d107975`. In the candidate's two captures without writes, sampled `__memcpy_generic` leaves with disk task creation as the first application caller accounted for about **2.00 and 1.82 µs of CPU per completed poll**. Matching libc debug symbols resolved these samples. Each capture completed 33,000 explicit offset polls, returning one message with a payload of 256 bytes per poll, with automatic commits disabled. The workload used one shard and one sequential TCP consumer in Docker Desktop's ARM64 Linux VM on an Apple M1 Pro. Linux perf sampled software `cpu-clock` at 499 Hz. These observations identify copying during task creation, but do not identify the copied object, measure all task construction work, or establish the elapsed cost of the completion box. Profiling can perturb execution. Subsequent changes to metric ownership and numeric history IDs reduced carried state, so the historical values cannot establish the remaining cost. #4174 records the shared evidence and its limits. In the inspected source, [read_poll](https://github.com/apache/iggy/blob/8f1c0e260076f9fbe49539e904e43895bc24c3fe/core/shard/src/poll.rs#L241) owns a `PollPlan`, and [PollCompletionSender::complete](https://github.com/apache/iggy/blob/8f1c0e260076f9fbe49539e904e43895bc24c3fe/core/shard/src/poll/completion.rs#L161) constructs `Box<PollCompleted>`. Their presence alone is not evidence that removing either allocation or ownership transfer would improve polling. **Investigation** - Inspect optimized future and payload sizes, allocation counts, and task creation caller stacks for an exact current release binary. Establish whether the historical copy signal survives. - Follow actual ownership transfers from plan construction through task execution, completion delivery and destruction. Account for copies, allocation placement and retained bytes throughout those lifetimes. - Reuse the parent's current diagnostics. Include polling with and without concurrent writes, recording achieved producer work so mixed server CPU is interpreted correctly. - If a material cost remains, compare one focused representation change against the same source without that change. Keep clean timings separate from instrumentation, validate returned work, and declare the worthwhile effect and measurement budget before confirmation. Report elapsed time, CPU and memory through completed polls, with uncertainty across independent runs. **Constraints and completion** Preserve reservation release, cancellation, late completion handling, history checks, owner acceptance and the disconnected requester guard. Removing boxing can enlarge futures or queue entries; pooling can increase retention. A standalone allocator benchmark omits these ownership and scheduling effects. Publish the measurements and decision. A supported finding that the remaining cost does not justify a change completes this issue. Fewer allocations alone do not establish an improvement. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
