Hi Dave,


StandardFileStream registry asArray size is 2.


> but it has no noticeable performance impact on my system.


I envy you. :-) No 5 - 10 minutes waiting for installing Metacello? No lagging Shout because it makes so many accesses to the changes file? :-) Yes, I already know that my source files access is extremely slow by comparison to others, even though my hardware/SSD specs and overall device speed are pretty satisfying. I never had the energy nor the right approach to investigate this issue. I can just observe that some of my images like to consume a lot of time in #open:forWrite:. Maybe the size of my images (often >1 GB) plus my occupied RAM (often <1 GB free) is a problem (more expensive GCs)? Maybe multiple images reading from the same sources file are a problem? Maybe Windows is indirecting accesses to the sources file which I have stored in the privileged folder C:\Program Files (x86)\ in an inefficient way? Maybe it's an issue with my disk or file system indeed? So many hypotheses to check ...


So, if we can optimize this in the image instead, this would be my preferred approach because it feels more holistic (thinking of raspis and SqueakJS etc.) and anyway, working in Squeak is more funny than "debugging" something in the dark cave below Squeak, of course. Thank you for the feedback! :-)


Best,

Christoph

________________________________
Von: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im Auftrag von David T. Lewis <lewis at mail.msen.com>
Gesendet: Freitag, 7. Januar 2022 02:41:53
An: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] Proper use of SourceFiles and "CurrentReadOnlySourceFiles cacheDuring:"

This is just a guess, but check the size of "StandardFileStream registry asArray"
in your image.

You are right that repeatedly opening and closing the sources
file and changes file is not a good thing, but it has no noticeable
performance impact on my system. I am on Linux and it may well
have a different impact on Windows, but I wonder if the time
may be going into the registry management as opposed to the
actual file open/close operations?

In my image:

  package := PackageInfo named: 'Tools'.
  [package overriddenMethods] timeToRun. ==> 53

Dave


On Thu, Jan 06, 2022 at 09:28:51PM +0000, 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.
>
>
> According to the profiler, 48% of the time are spent in StandardFileStream>>#unregister and 33% in StandardFileStream>>#open:forWrite:.
>
>
> 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.
>
>
> 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? 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! :-)
>
>
> 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 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!
>
>
> Best,
>
> Christoph

>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20220107/f30662a8/attachment.html>