Performance and Response Time
- response time
The response time of a system is the time that elapses between a user action
(keypress, mouse movement, ...) and the first sign that the system is
handling the request.
- The "desired" response time depends on the task or command
performed by the user.
The user forms her own model of what is a simple command and what is not.
Simple commands should result in response times of no more than 2 seconds.
- Variations in response time in similar situations should be avoided.
Multi-user systems are the most important cause of variations in response
time.
Even when a workstation is being used by only one person at a time,
multiple workstations sharing a file server may have the same effect as
multi-user systems.
- The time between typing a character and its echo on the screen should
be no more than 0.1 sec.
For workstations this may appear to be a trivial requirement.
Unfortunately, the introduction of swapping and paging (virtual memory)
has caused systems to not react quickly to the first character that is typed
after some time of inactivity.
- A response time of 2 seconds is acceptable when the system must:
- react to a user's command;
- produce a message;
- execute a "simple" command.
If the response time is a lot longer, the system should give an indication
that it is busy, and an estimate of the expected duration of the command.
- The load of the system (number of simultaneous users or tasks) should
not influence response time for user-interface actions, only for
non-user-interface actions.
This requirement could be met by systems if they allowed selective parts
of applications or window systems to be locked in memory.
Unfortunately this is not possible in popular systems like Unix and
Windows'95.
Swapping and paging are the most important cause for delays in reacting to
mouse movement or keys being pressed.
- performance
When the system is reacting to a user's action, the performance determines
how long that reaction will take.
- The system should be able to redraw the entire screen in under 1 second.
This constraint is not easily met when applications are subject to swapping
and paging.
Redrawing a screen of 1152x900 pixels in truecolor (24 bits per pixel)
means copying 3 Mbyte to the screen.
Although this is no problem for current I/O busses it is a problem if
these 3 Mbyte must be swapped in from disk first.
- When subsequent user actions imply that planned output will be
superseded very soon, intermediate output may be omitted.
The (Gosling) Emacs editor was one of the first text editors that
skips intermediate screen updates.
- When commands are entered when output is still pending,
the commands should be echoed already, and echoed again when the system
is ready for them.
Unix satisfies this requirement. VMS and MS-DOS are examples of systems
that do not echo a command until the system is ready for it.
- The mouse pointer (or cursor) should always follow the mouse movements
instantly.
Swapping and paging are again the limiting factors, even when
"hardware cursors" are used. These are supported by the graphics I/O board
and require no cpu-intervention. However the cursor is tracking the
mouse movement and the mouse is not connected directly to the graphics board.
- The mouse cursor (icon) must change itself instantly to the required
shape for the object the mouse is pointing at.
- Moving images (video) should always be smooth.
The bandwidth from cpu to the display hardware is largely sufficient on
modern workstations. The generation of the images is the limiting factor.
An increasing number of graphics boards have on-board MPEG decompression
for smoother video display.