andreaslind01 commented on PR #6359:
URL: https://github.com/apache/jmeter/pull/6359#issuecomment-5254144118

   Thanks for the fix. While this certainly addresses the immediate issue, I'm 
wondering whether we're solving the symptom rather than the root cause.
   
   Instead of inserting line breaks into large payloads, would it make sense to 
switch the request view to `JEditorPane` as well? The response view already 
uses `JEditorPane`, so we already have a proven solution for displaying large 
content without modifying the underlying data.
   
   I actually tested both approaches locally with very large payloads. Even 
with the inserted line breaks, rendering the request remains noticeably slow, 
likely because we still have to scan and transform the entire content before 
displaying it. In contrast, the `JEditorPane` solution stays responsive even 
with very large request bodies and does not require any preprocessing.
   
   My concern with the current approach is that we're introducing an additional 
preprocessing step that scans the entire content and injects artificial line 
breaks before rendering. For very large request bodies, that means we still 
have to process the whole payload and create a modified copy of it. We also end 
up displaying content that differs from the actual request.
   
   With `JEditorPane`, we could avoid:
   
   * running `StringWrap` on every large payload,
   * creating additional copies of large strings,
   * modifying the displayed request data,
   * maintaining special wrapping logic and its associated bugs,
   * having different implementations for request and response views.
   
   Since the response view already uses `JEditorPane` successfully, using the 
same component for requests would also make the implementation more consistent. 
Based on my tests, it is also significantly faster than the proposed wrapping 
approach for large content.


-- 
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]

Reply via email to