Path: csiph.com!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail From: Anton Shepelev Newsgroups: comp.lang.javascript Subject: Re: input/output parameters Date: Sat, 20 Mar 2021 14:56:30 +0300 Organization: A noiseless patient Spider Lines: 23 Message-ID: <20210320145630.62e1c4dde277c68dcd052e3e@gmail.com> References: <20210313153232.40fa0c8b0adf07d7e807084d@gmail.com> <20210315002732.dbb3221feb6d3a0c065292cf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Injection-Info: reader02.eternal-september.org; posting-host="0b6de666454792515201e0a3034742c6"; logging-data="7145"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19uN+o9yh2eSnClOMqvUrILVF+viIs9slg=" Cancel-Lock: sha1:nmoANA80YcnUS6wgp4VJ0UOONFA= X-Newsreader: Sylpheed 3.7.0 (GTK+ 2.24.30; i686-pc-mingw32) Xref: csiph.com comp.lang.javascript:39717 Jon Ribbens to Anton Shepelev: > > var /* number */ root ; eval( makeref( "root" ) ); > > var /* string */ errmsg; eval( makeref( "errmsg" ) ); > > Bear in mind that using 'eval' is extremely bad for > performance. It means the language runtime has to give up > on compilation and go back to using a basic interpreter. > And, stop trying to fight the language. You will end up > with terrible unreadable unmaintainable code. Thank you for this valuable comment. What is the scope of this negative effect of eval() -- current block, current function, or the entire program? It means I should not use my `makeref' function in performace-critical code sections. Fortunately, most of our code is going to have other performace bottlenecks, such as DB IO and interaction over network. -- () ascii ribbon campaign -- against html e-mail /\ http://preview.tinyurl.com/qcy6mjc [archived]