Read-only source files (was: Re: [squeak-dev] Why is source code always in files only?)

Levente Uzonyi leves at elte.hu
Tue Jan 20 21:31:17 UTC 2015


On Tue, 20 Jan 2015, Eliot Miranda wrote:

> 
> 
> On Tue, Jan 20, 2015 at 2:22 AM, Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com> wrote:
> 
>
>       2015-01-20 2:18 GMT+01:00 Eliot Miranda <eliot.miranda at gmail.com>:
> 
>
>             On Mon, Jan 19, 2015 at 5:09 PM, Levente Uzonyi <leves at elte.hu> wrote:
>                   On Mon, 19 Jan 2015, Eliot Miranda wrote:
> 
> 
>
>                         On Mon, Jan 19, 2015 at 1:31 PM, Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com> wrote:
>                               Hi Tobias,
>                               are you aware of CurrentReadOnlySourceFiles cacheDuring: [...]
>                         This is to workaround the readOnlyCopy used for thread safety which is the main killer of performance...
> 
>
>                         IMO this is a bug.  We should simply have a single read-only copy of each sources file and modify the debugger to either save and restore the state of a
>                         read-only copy around accessing source, or use its own
>                         read-only copy (except that the latter approach breaks when one debugs the debugger).  The difference in performance between using CurrentReadOnlySourceFiles
>                         cacheDuring: [...] and not in anything that
>                         accesses source is huge.  And CurrentReadOnlySourceFiles cacheDuring: [...] is a /lot/ of verbiage to type in doits, and a sign that something is wrong.
> 
>
>                   How would using a single copy solve the concurrency issues?
> 
> 
> It wouldn't, but what issues are you seeing in concurrent source access?  VW doesn't even have read-only copies and AFAICR we never had complaints about this.  Is there really a thread-safety
> issue here?
>  
> 
> 
> Couldn't there be a difference because VW properly handle read-append-stream for the underlying FILE?
> I have the feeling that such FILE is more robust to single write - multiple read concurrency, than a random-read-write FILE as used by Squeak...
> 
> 
> Maybe.  And Tim's point about the file api is well0-taken, but its much more work at the Smalltalk level than at the VM level.
> 
> However, I still want to see evidence of the potential thread-safety issues.  Access to the source files for writing is not thread-safe anyway but no one complains about that.  So I suspect we may be trying
> to fix a problem that doesn't really exist.  IMO it is much more preferable to have fast access to source than thread-safety.  If someone wants thread-safe access they can roll their own solution (e.g.
> install a wrapper hiding a mutex around the source files).  The common case of accessing source should be fast.  The difference between

I couldn't find out what the exact case was, but some tools (e.g. Slint) 
use background processes to examine a set of classes and their methods.

> 
>     self systemNavigation allSelect: [:m| m getSourceFromFile asString includesSubString: 'not likely']
> 
> and
> 
>     CurrentReadOnlySourceFiles cacheDuring: [self systemNavigation allSelect: [:m| m getSourceFromFile asString includesSubString: 'not likely']]
> 
> is 34 to 1 (!!), 28 seconds vs 0.8.

I guess your numbers include the time it takes for the OS to read the data 
from the disk. This is added to the first test of the first run, but it's 
not added to the second test, because then the files are already cached.

The numbers on my machine - ignoring the first run - are 3.215s and 
0.685s, which means 4.7x speedup.

Levente

> 
> :-(
> 
>
>                   I think the real solution would be to use per process copies, which were initialized lazily, and were closed automatically after some time of inactivity.
> 
> 
> If concurrent access was really an issue then OK.  But first I'd like some evidence that there's a real problem here.
> --
> best,Eliot
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> --
> best,Eliot
> 
>


More information about the Squeak-dev mailing list