On Fri, Jan 7, 2022 at 8:35 AM Levente Uzonyi <leves at caesar.elte.hu> wrote:

> Hi Christoph,
>
> On Thu, 6 Jan 2022, Thiede, Christoph wrote:
>
> >
> > Hi all!
> >
> >
> > While investigating why Squot is so slow in my image, I found out
> that the following takes ~7 seconds in my image:
> >
> >
> > package := PackageInfo named: 'Tools'.
> > [package overriddenMethods] timeToRun.
>
> That's very likely due to windows+anti-virus. 52ms here.
>
> >
> > According to the profiler, 48% of the time are spent
> in StandardFileStream>>#unregister and 33%
> in StandardFileStream>>#open:forWrite:.
>
> Are those the leaves or just random nodes in the tree?
>
> >
> >
> > By rewriting PackageInfo>>#changeRecordsForMethod:do: to use
> CurrentReadOnlySourceFiles rather than SourceFiles and wrapping the above
> invocation with "CurrentReadOnlySourceFiles cacheDuring:", I was able to
> reduce the run
> > time of my script to ~1.5 seconds.
>
> That's expected. :)
>
> >
> >
> > Now I wonder whether it is really so simple. Do I understand the class
> comment of CurrentReadOnlySourceFiles correctly that it is best practice to
> *always* use this fancy exception for any regular access to the source
> files?
>
> It is so simple, as long as the code is only reading from those files and
> the code doesn't try to close them.
>
> > If yes, why are we having so few senders to CurrentReadOnlySourceFiles
> class >> #at: and so many senders to SourceFiles? Are we having a huge
> chance to optimize the image by rewriting all these senders? If you think
> this a
> > good idea, I will be glad to do so! :-)
>
> There are so few senders, because
> - CurrentReadOnlySourceFiles is a "new" thing
> - CurrentReadOnlySourceFiles should actually be a ProcessLocalVariable,
> but when I created CurrentReadOnlySourceFiles, Squeak didn't have PLVs.
> - not everyone agrees on that concurrent source file reads outside the UI
> thread should be supported
>
> >
> >
> > And here's another question: Why do we need to close the sources file
> again and again at all. Whenever you navigate within any browsing tool (a
> very popular workload for some people here, I think), they are basically
> opened
>
> If you don't close the files, you'll run out of file descriptors and your
> image will stop working.
> Even if you don't close the files explicitly, the GC will do it, but that
> will be slower.
> It's also better to close them explicitly because it's not free (for the
> OS) to have the same file opened 500 times.
>
> > and closed upon every click, aren't they? Why can't we keep them open
> all the time? Is this to avoid data loss, or would it decelerate the
> operating system? Thanks in advance!
>
> If CurrentReadOnlySourceFiles were a PLV, there would practically be no
> need to close the files.
>

If the source file model supported something like
substituteReadOnlySourceFilesDuring: and
substituteWritableSourceFilesDuring:, the former being used in the
debugger, the l;atter when writing to the changes and sources files, then
we wouldn't need CurrentReadOnlySourceFiles at all.  The whole design is
backwards.  There is *no need* to create a new source file for every read;
that's insane.  There is only a need to avoid the debugger tripping over
itself.  There have never been any thread-safety guarantees with the
sources file and the UI ensures that compilation and browsing are
essentially single-threaded.  I wish we would engineer this properly and
not keep using the ugly CurrentReadOnlySourceFiles hack.  [and no criticism
is implied of you Levente; the thing works ok-ish, but things could be so
much better]


Levente
>


-- 
_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20220107/5d21e565/attachment.html>