SbloodyS commented on issue #18714: URL: https://github.com/apache/dolphinscheduler/issues/18714#issuecomment-6211317825
Both observations are valid based on the current implementation, but the expected benefits appear limited: - **Incremental result logging:** Rows are currently logged after the entire result set has been read. Logging them during iteration would improve visibility, but the additional traversal only covers `displayRows` (10 by default). The same row serialization and logging work would still be required, so the performance benefit should be small. - **Alert content serialization:** The truncation loop does repeatedly serialize and UTF-8 encode the remaining candidate rows. However, the candidates are already capped at 30 rows by default, and repeated work only occurs when the content exceeds the byte budget. The optimization would therefore mainly benefit unusually wide results or larger configured row limits. Neither change removes the need to retain and serialize the complete task result. Without benchmark evidence of a meaningful bottleneck, I would favor keeping the implementation simple. Adding cached row representations, byte accounting, and omission-marker handling could introduce more maintenance cost than these limited benefits justify. A straightforward change to improve log timing may still be worthwhile, but we should avoid adding complexity solely for small performance gains. -- 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]
