From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: "Stefan Monnier " Newsgroups: gmane.emacs.help Subject: Re: About performance, hash-tables and garbage collection Date: 20 Sep 2002 17:07:38 -0400 Organization: Yale University Sender: help-gnu-emacs-admin@gnu.org Message-ID: <5lfzw4nzdx.fsf@rum.cs.yale.edu> References: NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1032557608 18405 127.0.0.1 (20 Sep 2002 21:33:28 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Fri, 20 Sep 2002 21:33:28 +0000 (UTC) Return-path: Original-Received: from monty-python.gnu.org ([199.232.76.173]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 17sVOw-0004mh-00 for ; Fri, 20 Sep 2002 23:33:27 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10) id 17sVPN-0003dr-00; Fri, 20 Sep 2002 17:33:53 -0400 Original-Path: shelby.stanford.edu!nntp.stanford.edu!newsfeed.stanford.edu!newsfeed.berkeley.edu!news-hog.berkeley.edu!ucberkeley!news.ycc.yale.edu!rum.cs.yale.edu!rum.cs.yale.edu Original-Newsgroups: gnu.emacs.help Original-Lines: 35 Original-NNTP-Posting-Host: rum.cs.yale.edu User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 X-Original-NNTP-Posting-Host: rum.cs.yale.edu X-Original-Trace: 20 Sep 2002 17:07:38 -0400, rum.cs.yale.edu Original-Xref: nntp.stanford.edu gnu.emacs.help:105127 Original-To: help-gnu-emacs@gnu.org Errors-To: help-gnu-emacs-admin@gnu.org X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.help:1679 X-Report-Spam: http://spam.gmane.org/gmane.emacs.help:1679 > 1. I have read that hash-tables have a little overhead and that > association lists are a little bit faster, when they contain not > more than about a dozen of key-value pairs. It is _possible_ that I > have to maintain several hundreds or thousand of key/value pairs, > but in most cases it will be only a dozen or so. So my question is: > how much overhead has a hashtable? Makes it sense to add a > condition, like this: > (if (> ncolours 15) > (gethash colour colour-map) > (cdr (assoc (colour colour-map)))) The `if' overhead will probably dwarf the difference, so I'd say, just use the hash-table. Most likely any performance problem you'll have won't come from that anyway. > 2. I noticed that the garbage collector hits in a little bit too often, What's too often ? Why do you care ? Does it use a significant percentage of the running time ? If yes, look for things like `append' and things like that to see where you do most allocation. > though I do not know why. I have a lot of `setq'-statements > like `(setq pointer (1+ pointer))'. Is it possible that they are > the cause? If the code is interpreted, maybe, tho I don't think so. > If so, what could I do? If you've byte-compiled your code, then an increment (as shown above) will not allocate any memory and will thus have no influence on GC. Stefan