Re: [Pharo-dev] Faster ThreadSafeTranscript Re: [pharo-project/pharo-core] 06d05b: 40165

[Ben Coman]

Guillermo Polito wrote: Well, I have no idea why that line is there :). It's old (so I do not remember), a tweak (read ´hack´) I probably did to make the bootstrap work at the time, and I don't think it's correct that line is there, so maybe we should remove it? :) Okay.  I'll leave that to you guys.  I'm happy to proceed on the basis that its not "expected" to break anything. cheers -ben On Tue, Aug 12, 2014 at 10:03 PM, Max Leske <maxle...@gmail.com> wrote: On 12.08.2014, at 14:27, Ben Coman <b...@openinworld.com> wrote: GitHub wrote: Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: 06d05bd822deee4a79736d9f99d4a666ca1637eb https://github.com/pharo-project/pharo-core/commit/06d05bd822deee4a79736d9f99d4a666ca1637eb Author: Jenkins Build Server <bo...@pharo-project.org> Date: 2014-08-11 (Mon, 11 Aug 2014) 13806 Remove ThreadSafeTranscriptPluggableTextMorph https://pharo.fogbugz.com/f/cases/13806 For anyone concerned about the performance of writing to Transcript from higher priority threads, just reporting that altering ThreadSafeTranscript to be safe for Morphic without ThreadSafeTranscriptPluggableTextMorph had a side effect of enhancing performance by 25x.   With two runs of the following script...     Smalltalk garbageCollect.     Transcript open. "close after each run"     [    Transcript crShow: (              [             | string |             string := '-'.                1 to: 2000 do:             [        :n |                      string := string , '-', n printString.                     Transcript show: string.             ].             (Delay forMilliseconds: 10) wait.         ]) timeToRun.     ] forkAt: 41. Build 40162 reports timeToRun of 0:00:00:02.483 & 0:00:00:02.451 Build 40165 reports timeToRun of 0:00:00:00.037 & 0:00:00:00.099 Now I had meant to ask... I notice that FLFuelCommandLineHandler installs ThreadSafeTranscript, so I wonder it is affected by this change. Can some Fuel experts comment? Hi Ben I tried to figure this out with Mariano. Apparently the Transcript parts come from an improvement that was suggested by Pavel Krivanek (see this issue: http://code.google.com/p/pharo/issues/detail?id=6428). The code presumably was tailored to the needs that Hazel (today called Seed http://smalltalkhub.com/#!/~Guille/Seed) had. We couldn’t find any other reason why we would do *anything* Transcript related, especially since the command line handlers print to stdout anyway. Mariano suggested I CC Ben and Guille, so I’m doing that. Maybe one of the two can shed some light on that method. From my point of view I don’t see why we should keep that part of the code. Cheers, Max Also I am looking for some advice for a minor downside I just noticed.  The whole script above can complete between steps, so the entire output ends up in the PluggableTextMorph its size without being culled, which causes making a selection become really slow.  Normally the excess text shown by Transcript is culled in half [1] by PluggableTextMorph>>appendEntry each time #changed: is called. PluggabletextMorph>>appendEntry     "Append the text in the model's writeStream to the editable text. "     textMorph asText size > model characterLimit ifTrue:   "<---[0]"         ["Knock off first half of text"         self selectInvisiblyFrom: 1 to: textMorph asText size // 2.   "<---[1]"         self replaceSelectionWith: Text new].     self selectInvisiblyFrom: textMorph asText size + 1 to: textMorph asText size.     self replaceSelectionWith: model contents asText.  "<----[2]"     self selectInvisiblyFrom: textMorph asText size + 1 to: textMorph asText size That works fine when #appendEntry is being called with lots of small changes, but for a single large change the entire change ends up in PluggableTextMorph via [2]. In this case     model characterLimit  "--> 20,000"     [0]     model contents size "--> 5,671,343"    [2] where model == Transcript. So what is the behaviour you'd like to when too much is sent to Transcript? a. Show all content however briefly. b. Only the last 20,000 characters are put into the PluggableTextMorph, and the earlier data thrown away. I see a few ways to deal with this: 1. Limit the stream inside Transcript to a maximum 20,000 characters by basing it on some circular buffer. 2. Have "Transcript conents" return only the last 20,000 characters of its stream. 3. Limit to text sent to #replaceSelectionWith: [2]  to 20,000 characters. Thoughts anyone? cheers -ben