Number: 1419

Date: 14-Jun-84 14':58':33

Submitter: Sannella.PA

Source: Masinter.pa

Subject: Reduce workingset of programming enviornment loop

Assigned To: 

Attn: Lisp, Masinter, JonL

Status: Open

In/By: 

Problem Type: Performance

Impact: Moderate

Difficulty: Hard

Frequency: 

Priority: Perhaps

System: Programming Environment

Subsystem: Code Editor

Machine: 

Disk: 

Lisp Version: 

Source Files: 

Microcode Version: 

Memory Size: 

File Server: 

Server Software Version: 

Disposition: '
["Masinter" " 5-Sep-84 17':40':49" Attn': Description':]

Description: '
Description':I assigned this to "editor" but it fits in with a number of other applications. As Gordon Novak reported quite a while ago, the memory '
requirements of the Interlisp-D read/edit/debug/etc. look are very very high. '
It was unreasonably high. One of the major complaints about the "unusable" '
performance on the 1100 and 1108 with 1.5 MByte was exactly that the '
environment workingset was too big. Now, ano matter how much memory you add, '
this is an issue because once you''ve run an application, your enviornment gets paged out, and the time to page it in is proportional to its workingset--- more memory won''t help in the long run, unless the calculation and the editor all fit into the memory of the machine. Now, what to do? The first thing is to run with RELEASEWORKINGSET and COREHAX thru the loop of doing a LOADFROM of a program, editing it using DEDIT, running it, hitting a breakpoint, showing the stack, etc. and look and see what gets swapped in, using COREHAX and possibly some better tools developed for this purpose. We might need to write something that logs what pages get swapped in and what datatype they are.  What actually has to change can only be determined after more investigation.'
'
Date': 29 Jun 1982 2218-PDT'
From': Novak at SUMEX-AIM'
Subject': Dolphin Working Set'
To':   Masinter at PARC-MAXC'
cc':   Schoen at SUMEX-AIM, Rindfleisch at SUMEX-AIM'
'
I tried the working set test you suggested.  After (RELEASEWORKINGSET)'
I got (in octal)'
1631 Pages in use'
2546 empty'
4377 total available'
1217 pages locked'
   4 dirty.'
'
The Empty figure is 1382 pages decimal.  After doing various things,'
I got the following decreases in the Empty figure (decimal)':'
GLISP compile':       477'
GLISP + EDIT/TTYIN': 1191'
EDIT/TTYIN alone':    835'
This indicates that EDIT alone takes up 60% of the free pages, and'
would certainly explain the large amount of paging if the user wanted'
to have some of his own code around in addition to the editor.'
As Eric''s message suggests, more real memory would undoubtedly help'
performance.  However, this seems to me like a lot of memory just for'
the editor.  After all, 1 MB is roughly equal to the whole DEC-20'
address space; surely the editor doesn''t take up 40% of the whole'
address space on a 20.  This suggests that the storage used by EDIT'
and TTYIN is fragmented across many pages [this TTYIN is separately'
loaded], and that with some care the most-used parts might be located'
together in a much smaller number of pages.  For the editor, at least,'
this would seem well worth the trouble.'
'
Thanks, Gordon'
'


Workaround: 

Test Case: 

Edit-By: Masinter

Edit-Date:  5-Sep-84 17':40':49