From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier via Users list for the GNU Emacs text editor Newsgroups: gmane.emacs.help Subject: Re: [External] : Passing buffers to function in elisp Date: Fri, 03 Mar 2023 10:19:09 -0500 Message-ID: References: <87mt56hg4e.fsf@iki.fi> <87bklihln8.fsf@iki.fi> <87pm9yf0ph.fsf@web.de> <87v8jmkfd0.fsf@iki.fi> Reply-To: Stefan Monnier Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="4886"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) To: help-gnu-emacs@gnu.org Cancel-Lock: sha1:ojJJzRjfH3rg2mptapv7maUvylo= Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Fri Mar 03 16:20:01 2023 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pY7CS-000134-Mb for geh-help-gnu-emacs@m.gmane-mx.org; Fri, 03 Mar 2023 16:20:00 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pY7Bv-0003W6-58; Fri, 03 Mar 2023 10:19:27 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pY7Bq-0003VE-Iy for help-gnu-emacs@gnu.org; Fri, 03 Mar 2023 10:19:23 -0500 Original-Received: from ciao.gmane.io ([116.202.254.214]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pY7Bo-0005wL-Rx for help-gnu-emacs@gnu.org; Fri, 03 Mar 2023 10:19:22 -0500 Original-Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1pY7Bl-000Abm-7f for help-gnu-emacs@gnu.org; Fri, 03 Mar 2023 16:19:17 +0100 X-Injected-Via-Gmane: http://gmane.org/ Received-SPF: pass client-ip=116.202.254.214; envelope-from=geh-help-gnu-emacs@m.gmane-mx.org; helo=ciao.gmane.io X-Spam_score_int: -16 X-Spam_score: -1.7 X-Spam_bar: - X-Spam_report: (-1.7 / 5.0 requ) BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.help:142908 Archived-At: > Also, if I interpreted profiler's hieroglyphs correctly, it told me that > this setq > > (setq stream (vconcat stream (plist-get page :stream))) This is a typical a source of unnecessary O(Nē) complexity: the above line takes O(N) time, so if you do it O(N) times, you got your Nē blowup. You're usually better off doing (push (plist-get page :stream) stream-chunks) and then at the end get the `stream` with (mapconcat #'identity (nreverse stream-chunks) nil) or (apply #'vconcat (nreverse stream-chunks)) Of course that depends on what else happens with `stream` (I haven't really looked at your code, sorry). > I think I can replace vectors with strings, which should, according to > the elisp manual, "occupy one-fourth the space of a vector of the same > elements." More likely one-eighth nowadays (64 bit machines). > Similarly bindat consumes a lot of memory. Hmm... IIRC it should not use up very much "auxiliary" memory. IOW its memory usage should be determined by the amount of data it returns. So, when producing the bytestring it should be quite efficient memorywise. When reading the bytestring it may be wastefully allocating memory for all the alists (and also it may be wasteful if you only need some info because you still need to parse everything and allocate data to represent its parsed form). > But bindat internals are beyond me. I can be of help here :-) >> That's definitely something to consider. Another is whether the ELisp >> code was byte-compiled (if not, then all bets are off, the interpreter >> itself generates a fair bit of garbage, especially if you use a lot of >> macros). > No, it was not byte-compiled. Then stop right there and fix this problem. There's absolutely no point worrying about performance (including memory use) if the code is not compiled because compilation can change the behavior drastically. The only reason to run interpreted code nowadays is when you're Edebugging a piece of code. > I'll try byte-compiling after the code is in good enough shape to do > controlled experiments. The compiler is your friend. He can help you get the code in good shape :-) Stefan