The version of Apache log4j used by SoundHelix.

[[ 🗃 ^aEp6o apache-log4j ]] :: [📥 Inbox] [📤 Outbox] [🐤 Followers] [🤝 Collaborators] [🛠 Commits]

Clone

HTTPS: git clone https://vervis.peers.community/repos/aEp6o

SSH: git clone USERNAME@vervis.peers.community:aEp6o

Branches

Tags

v_1_1b5 :: contribs / JamesHouse /

mail-2001-01-23

Delivered-To: urba-cgu@urbanet.ch 
From: James House <james.house@medibuy.com> 
To: Ceki Gulcu <cgu@urbanet.ch> 
Subject: RE: Buffering issues 
Date: Tue, 23 Jan 2001 11:38:30 -0800 
X-Mailer: Internet Mail Service (5.5.2650.21) 



Ceki,


Most of the "speed" issues can be easily solved, as demonstrated in
the new versions of the files that are attached, and as described
here:


The "drawing" of the panel is time consuming. And let's face it: we
will never build a swing component that can re-draw itself thousands
of times per second - nor could the human eye keep up with that anyway
(60-ish redraws per second is the limit of what most humans can
perceive).


I think you'll agree that regardless of which choice of swing
components, the issue of not being able to draw more than 100 times
per second (if that) will be a constant.


Possible solutions to wasting a lot of time redrawing are:
  * Redraw every N messages
  * Redraw every N milliseconds
  * Redraw when a message of a high priority is received
  * Only redraw if the changes (new messages) are visible (depending on
scroll-bar position)



I made some very small changes (which are some of what I outlined in
the previous e-mail as things on the to-do list), and you should be
able to see a great difference in performance.


In general the changes are: Use a "queue" to asynchronously deliver
the messages to the panel for updating, rather than having the calling
thread (the one generating the log message) be responsible for
re-drawing the panel - this frees up the thread to continue on without
waiting for the logging mechanism.  The "queue" has a thread that
wakes up every N milliseconds, or when a message of a specified
priority arrives. It then delivers all queued messages to the panel,
which then redraws ONCE for the entire batch of queued messages IF the
new messages are visible in the display.


With the "tail" mechanism turned on (so that any new set of messages
forces a redraw, because the last message is always visible), the
panel can now log about a thousand messages in 1 second. With tail
turned off (so that redraw is only required if the panel is showing
the space the new messages will be printed), it can receive over a
100,000 messages in just a few seconds.  Also, most of the flicker is
already eliminated.


Again, everything in the code is really "roughed in" - just there to
give the general idea, not necessarily to do things in the best way -
but I really feel that this kind of solution is what you'll have to
end up with in the long term.


James
[See repo JSON]