<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Exchange Server">
<!-- converted from text --><style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; } --></style>
</head>
<body>
<meta content="text/html; charset=UTF-8">
<style type="text/css" style="">
<!--
p
{margin-top:0;
margin-bottom:0}
-->
</style>
<div dir="ltr">
<div id="x_divtagdefaultwrapper" dir="ltr" style="font-size:12pt; color:#000000; font-family:Calibri,Helvetica,sans-serif">
<p>Hi Dave,</p>
<p><br>
</p>
<p><span>StandardFileStream registry asArray size is 2.</span></p>
<p><span><br>
</span></p>
<p><span>> </span><span style="font-size:12pt">but it has no noticeable </span><span style="font-size:12pt">performance impact on my system.</span></p>
<p><span style="font-size:12pt"><br>
</span></p>
<p><span style="font-size:12pt">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 #<span>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 ...</span></span></p>
<p><span style="font-size:12pt"><span><br>
</span></span></p>
<p><span style="font-size:12pt"><span>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! :-)</span></span></p>
<p><span style="font-size:12pt"><span><br>
</span></span></p>
<p><span style="font-size:12pt"><span>Best,</span></span></p>
<p>Christoph</p>
</div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="x_divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>Von:</b> Squeak-dev <squeak-dev-bounces@lists.squeakfoundation.org> im Auftrag von David T. Lewis <lewis@mail.msen.com><br>
<b>Gesendet:</b> Freitag, 7. Januar 2022 02:41:53<br>
<b>An:</b> The general-purpose Squeak developers list<br>
<b>Betreff:</b> Re: [squeak-dev] Proper use of SourceFiles and "CurrentReadOnlySourceFiles cacheDuring:"</font>
<div> </div>
</div>
</div>
<font size="2"><span style="font-size:10pt;">
<div class="PlainText">This is just a guess, but check the size of "StandardFileStream registry asArray"<br>
in your image.<br>
<br>
You are right that repeatedly opening and closing the sources<br>
file and changes file is not a good thing, but it has no noticeable<br>
performance impact on my system. I am on Linux and it may well<br>
have a different impact on Windows, but I wonder if the time<br>
may be going into the registry management as opposed to the<br>
actual file open/close operations?<br>
<br>
In my image:<br>
<br>
package := PackageInfo named: 'Tools'.<br>
[package overriddenMethods] timeToRun. ==> 53 <br>
<br>
Dave<br>
<br>
<br>
On Thu, Jan 06, 2022 at 09:28:51PM +0000, Thiede, Christoph wrote:<br>
> Hi all!<br>
> <br>
> <br>
> While investigating why Squot is so slow in my image, I found out that the following takes ~7 seconds in my image:<br>
> <br>
> <br>
> package := PackageInfo named: 'Tools'.<br>
> [package overriddenMethods] timeToRun.<br>
> <br>
> <br>
> According to the profiler, 48% of the time are spent in StandardFileStream>>#unregister and 33% in StandardFileStream>>#open:forWrite:.<br>
> <br>
> <br>
> 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.<br>
> <br>
> <br>
> 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! :-)<br>
> <br>
> <br>
> 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!<br>
> <br>
> <br>
> Best,<br>
> <br>
> Christoph<br>
<br>
> <br>
<br>
<br>
</div>
</span></font>
</body>
</html>