I opened a case for removing ThreadSafeTranscript from the FLCommandlineHandler. Proposed slice is in inbox.
Cheers, Max On 13.08.2014, at 19:17, Eliot Miranda <[email protected]> wrote: > > > > On Wed, Aug 13, 2014 at 8:24 AM, Ben Coman <[email protected]> wrote: > Eliot Miranda wrote: >> >> On Tue, Aug 12, 2014 at 5:27 AM, Ben Coman <[email protected]> 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 <[email protected]> >>> 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? >> >> >> 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 contents" return only the last 20,000 characters of its >> stream. >> 3. Limit to text sent to #replaceSelectionWith: [2] to 20,000 characters. >> >> Thoughts anyone? >> >> IMO 20,000 characters is way too little. I routinely set my limit to >> 200,000. So b) but with a higher limit. a) is pointlessly slow. > Thanks Eliot. Its good to know what is expected from Transcript. >> >> In your implementation list, surely 2. is the only thing that makes sense? > > I agree, (2.) would be efficient. It just would have been precluded if (a) > was required. > >> If the limit can remain soft then anyone that wants to see more simply >> raises their limit. > > Do you mean you'd like Transcript characterLimit to be a Preference ? > > I'm not sure. If it was a preference I'd use it, but few others may find it > useful. As I say, I need at east 20,000 chars on the transcript to > effectively develop Cog; the VM simulator produces lots of output and > realistically a transcript is the only convenient place to view it. So > whether it was a preference ofr not I'd make sure the limit was >= 20k. > >> 1. & 3. are implementation details left up to you. > > I can do (1.) with Steph's new circular list. Doing (2.) means (3.) wont be > required for this, but its probably beneficial so I'll log it as separate > Issue. > >> As long as the transcript is reasonably fast and has the same protocol as >> WriteStream (it needs to support printOn: and storeOn: et al) implement it >> as you will. BTW, the Squeak transcript is appallingly slow. > -- > best, > Eliot
