Hi Levente,

On Tue, Jan 20, 2015 at 1:31 PM, Levente Uzonyi <leves at elte.hu> wrote:

> 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.


Good point. When I run the cacheing version first my times are

640ms vs 6589ms, 10.3 to 1.  That's still very large.


>
>
> 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
>>
>>
>
>
>


-- 
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20150120/2c53d543/attachment.htm