From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/7487 Path: main.gmane.org!not-for-mail From: Ken Raeburn Newsgroups: gmane.emacs.gnus.general Subject: Re: [ patch ] async stuff fix(?) (was Re: 0.3 and async pre-fetch) Date: 05 Aug 1996 14:20:53 -0400 Sender: raeburn@cygnus.com Message-ID: References: NNTP-Posting-Host: coloc-standby.netfonds.no X-Trace: main.gmane.org 1035147793 7398 80.91.224.250 (20 Oct 2002 21:03:13 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 20 Oct 2002 21:03:13 +0000 (UTC) Cc: ding@ifi.uio.no Return-Path: ding-request@ifi.uio.no Original-Received: from ifi.uio.no (ifi.uio.no [129.240.64.2]) by deanna.miranova.com (8.7.5/8.6.9) with SMTP id LAA30575 for ; Mon, 5 Aug 1996 11:30:37 -0700 Original-Received: from cygnus.com (cygnus.com [140.174.1.1]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Mon, 5 Aug 1996 20:21:07 +0200 Original-Received: from tweedledumb.cygnus.com (tweedledumb.cygnus.com [192.80.44.1]) by cygnus.com (8.6.12/8.6.9) with SMTP id LAA05971; Mon, 5 Aug 1996 11:20:58 -0700 Original-Received: from cujo.cygnus.com by tweedledumb.cygnus.com (4.1/4.7) id AA04298; Mon, 5 Aug 96 14:20:55 EDT Original-Received: by cujo.cygnus.com; (5.65v3.2/1.1.8.2/20Sep95-0235PM) id AA27343; Mon, 5 Aug 1996 14:20:54 -0400 Original-To: Sudish Joseph In-Reply-To: Sudish Joseph's message of 04 Aug 1996 18:09:51 -0400 Original-Lines: 52 X-Mailer: Gnus v5.2.32/Emacs 19.31 Xref: main.gmane.org gmane.emacs.gnus.general:7487 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:7487 Sudish Joseph writes: > The downside to using strings is that we'll get -large- strings that > will hog memory until garbage collection. I think that'll be bad for performance. Remember emacs does gc roughly after each N bytes allocated. So if you get a large string per article, say, you'll be doing gc very often as you go through one newsgroup. (Just building a summary buffer for 1000 articles causes me to run gc several times. That's part of the reason for the simplified-subject-caching speedups I sent mail about a while back. At some point interning in a symbol table once is cheaper than regenerating multiple copies of the same strings over and over.) Also, the cost of doing a gc is, I think, dependent on the currently allocated storage and the max-so-far allocated storage. (Has anyone looked at it more closely? I think only buffers are allocated from storage that can get freed, but I could be wrong.) So allocating big strings that can't be gc'ed right away means the price of future gc passes probably goes up. Can you return articles or other big stuff as buffers or buffer portions? (Carefully arranging to always have them cleaned up, of course.) > Is there any way to > truncate the actual string to get around this? (It has to be there, > I'm too lazy to dig right now.) Even better, any way to totally > obliterate the in-memory string; i.e., gc a single string? None I know of. > I don't > think the number of actual strings generated will increase gc costs. > If so, we might keep a constant number of strings that we grow and > truncate as needed. Hmm, do buffers cost more/less than strings? We > might pass buffers as our result from the filter if that's better. > Buffers aren't gc'ed I think, but we can manually maintain those quite > easily. A buffer should be more expensive than a string, but passing around lots of mark in a single buffer may be cheaper than manipulating lots of substrings. The buffer contents don't go through the alloc/gc interface that strings and other objects use. > PS: If anyone would care to explain: can buffers be gc'ed? are > lambda's gc'ed (if not, gnus currently leaks)? can an arbitrary > object be completely destroyed/gc'ed all by itself? I think you have to explicitly kill buffers first; yes; no.