Mailing-List: contact issues-help@jmeter.apache.org; run by ezmlm
Precedence: bulk
Reply-To: issues@jmeter.apache.org
From: bugzilla@apache.org
To: issues@jmeter.apache.org
Subject: [Bug 60687] Make GUI more responsive when it gets a lot of events
Date: Mon, 13 Feb 2017 12:58:54 +0000
Message-ID: <bug-60687-58895-0XNTHavX9n@https.bz.apache.org/bugzilla/>
In-Reply-To: <bug-60687-58895@https.bz.apache.org/bugzilla/>
References: <bug-60687-58895@https.bz.apache.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Auto-Submitted: auto-generated
MIME-Version: 1.0
archived-at: Mon, 13 Feb 2017 12:59:23 -0000

https://bz.apache.org/bugzilla/show_bug.cgi?id=3D60687

--- Comment #16 from Vladimir Sitnikov <sitnikov.vladimir@gmail.com> ---
Felix> Could you be a bit more specific here?

For instance,
1) Things like "model.insertRow" do require to be executed on the AWT threa=
d.
I'm not sure how hard it could break, however accessing UI thread on the hot
path is bad.

2) Table rendering code (that is run on the UI thread) accesses computed va=
lues
without any synchronization. This might result in word tearing, stale value=
s,
unexpected division by zero, etc.


Felix> Right. Get swing out of the path and be happy.

This kind of change would likely to heal 1 above, however it might look lik=
e a
"complete rewrite of the relevant listener code".

Even if we move swing calls out of hot path, we would still need some fast =
way
to aggregate values.
For instance, "Total" row could be computed "on UI refresh" to avoid global
synchronization of all the threads.

From one point of view this might look like a over engineering, on the other
hand, that might be reused for "non-gui console mode" listeners.

--=20
You are receiving this mail because:
You are the assignee for the bug.=