From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10179 invoked by alias); 19 Aug 2017 05:19:15 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 41573 Received: (qmail 26891 invoked by uid 1010); 19 Aug 2017 05:19:15 -0000 X-Qmail-Scanner-Diagnostics: from aok120.rev.netart.pl by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.99.2/21882. spamassassin: 3.4.1. Clear:RC:0(85.128.245.120):SA:0(-1.9/5.0):. Processed in 4.557272 secs); 19 Aug 2017 05:19:15 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.1 X-Envelope-From: psprint@zdharma.org X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | X-Virus-Scanned: by amavisd-new using ClamAV (1) Date: Sat, 19 Aug 2017 07:06:00 +0200 From: Sebastian Gniazdowski To: Bart Schaefer Cc: "=?utf-8?Q?zsh-workers=40zsh.org?=" Message-ID: In-Reply-To: References: Subject: Re: Can ZWC be optimized, for lesser depths of recursive exec* calls? X-Mailer: Airmail (442) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On 20.07.2017 at 19:40:33, Bart Schaefer (schaefer=40brasslantern.com) wr= ote: > To some extent you're having a deeper variation of the same confusion > that Ray Andrews sometimes has, namely, distinguishing characteristics > of an interpreted language from a compiled one. With a true compiled > language, the syntax and semantics can both be analyzed at compile > time, but in an interpreted language the semantics aren't fully > expressed until run time. In this case the chain of exec.c function > calls traces the semantics of the language -- reconstructing the parse > tree, traversing it, and executing it, all at the same time. Today instead of looking at large OS X Instruments call tree, I've added = function-name-printing to each *exec* (plus addvars) function in exec.c. = This way execution looks much more normal and exec.c code seems quite com= pact now, not so many such functions there. Basically following repeats f= or any execution-code item (not e.g. function-definition item): =C2=A0 execlist -> execpline -> execpline2 -> execcmd=5Fexec. =46unction execsimple() can do assignment and function-definition (there'= s also some general-purpose else =7B=7D but it's rather not used, as cont= rol should go general-purpose earlier, before execsimple, if needed). Did= n't track WC=5FSIMPLE yet. I have a hard time establishing where CPU-time dissipates. It's a gradual= process, and exec.c functions happen to be long. However I see that my r= equests to help in optimizing zwc have been rather asking for doing somet= hing with the 4 above typical calls, and yeah, they're typical, rather no= thing to do with them. > This is crucial for accurately reproducing the original script flow in > xtrace output. Simplifying the ZWC would amount to rewriting the > script -- looking at xtrace output would be like stepping through an > optimized C program with a debugger: the program counter would no > longer correspond to the source. I have this automated. (z) flag and state tracking, and voila, automatic = function extraction: % zplg lexicon convert zdharma/fast-syntax-highlighting Extracted =C2=A047-line function =60=5Fzsh=5Fhighlight'... Extracted =C2=A021-line function =60=5Fzsh=5Fhighlight=5Fapply=5Fzle=5Fhi= ghlight'... Extracted =C2=A034-line function =60=5Fzsh=5Fhighlight=5Fbind=5Fwidgets'.= .. Extracted =C2=A0 2-line function =60=5Fzsh=5Fhighlight=5Fbuffer=5Fmodifie= d'... Extracted =C2=A0 2-line function =60=5Fzsh=5Fhighlight=5Fcall=5Fwidget'..= . Extracted =C2=A0 2-line function =60=5Fzsh=5Fhighlight=5Fcursor=5Fmoved'.= .. Extracted =C2=A0 3-line function =60=5Fzsh=5Fhighlight=5Fpreexec=5Fhook'.= .. Generated preamble ( 21 lines) =23 this is .plugin.zsh file stripped of f= uns % pwd /Users/sgniazdowski/.zplugin/lexicon % ls =5Fzsh=5Fhighlight =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =5Fzsh=5Fhighlight=5Fcall=5Fwidget =5Fzsh=5Fhighlight=5Fapply=5Fzle=5Fhighlight =5Fzsh=5Fhighlight=5Fcursor=5F= moved =5Fzsh=5Fhighlight=5Fbind=5Fwidgets =C2=A0 =C2=A0 =C2=A0 =C2=A0=5Fzsh=5Fh= ighlight=5Fpreexec=5Fhook =5Fzsh=5Fhighlight=5Fbuffer=5Fmodified % file ../lexicon.zwc ../lexicon.zwc: data So if user wants xtrace, he can revert to-lexicon-conversion and run plug= in normally. The problem is that lexicon seems to be 2-3 ms slower. Not m= uch, can treat this as the-same-speed, however, it should be faster to ju= stify doing this. Or at least have some not-speed-related features. Seein= g plugin's functions as files is cool, but I need something more. -- =20 Sebastian Gniazdowski psprint /at/ zdharma.org