From mboxrd@z Thu Jan  1 00:00:00 1970
Path: main.gmane.org!not-for-mail
From: Jesper Harder <harder@myrealbox.com>
Newsgroups: gmane.emacs.help
Subject: Re: Does network data really cons strings?
Date: Tue, 13 Jan 2004 04:17:18 +0100
Organization: http://purl.org/harder/
Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org
Message-ID: <m34qv0a669.fsf@defun.localdomain>
References: <m37jzwonei.fsf@defun.localdomain> <40032235.3050709@yahoo.com>
NNTP-Posting-Host: deer.gmane.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Trace: sea.gmane.org 1073964612 13079 80.91.224.253 (13 Jan 2004 03:30:12 GMT)
X-Complaints-To: usenet@sea.gmane.org
NNTP-Posting-Date: Tue, 13 Jan 2004 03:30:12 +0000 (UTC)
Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Tue Jan 13 04:30:09 2004
Return-path: <help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org>
Original-Received: from monty-python.gnu.org ([199.232.76.173])
	by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian))
	id 1AgFFp-0006TG-00
	for <geh-help-gnu-emacs@m.gmane.org>; Tue, 13 Jan 2004 04:30:09 +0100
Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org)
	by monty-python.gnu.org with esmtp (Exim 4.24)
	id 1AgGCj-0000Dp-UL
	for geh-help-gnu-emacs@m.gmane.org; Mon, 12 Jan 2004 23:31:01 -0500
Original-Path: shelby.stanford.edu!newsfeed.stanford.edu!news.tele.dk!news.tele.dk!small.news.tele.dk!not-for-mail
Original-Newsgroups: gnu.emacs.help
X-Face: ^RrvqCr7c,P$zTR:QED"@h9+BTm-"fjZJJ-3=OU7.)i/K]<.J88}s>'Z_$r;
	<N5ksn~%wJ@2pjF}="tV; FBsdpFarSWA<oYkZsViGf:F^SD-KXhvFxh;
	~]?)SWm~+u}; 0=x}<vOm&5J+?]yB2d]q4x8\0g7SX
Mail-Copies-To: never
User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3.50 (gnu/linux)
Cancel-Lock: sha1:tMfXbo8OJWHgJw/y5LDSx4MfBxY=
Original-Lines: 41
Original-NNTP-Posting-Host: 195.249.83.88
Original-X-Trace: 1073963890 dtext02.news.tele.dk 161 195.249.83.88:41738
Original-X-Complaints-To: abuse@post.tele.dk
Original-Xref: shelby.stanford.edu gnu.emacs.help:120025
Original-To: help-gnu-emacs@gnu.org
X-BeenThere: help-gnu-emacs@gnu.org
X-Mailman-Version: 2.1.2
Precedence: list
List-Id: Users list for the GNU Emacs text editor  <help-gnu-emacs.gnu.org>
List-Unsubscribe: <http://mail.gnu.org/mailman/listinfo/help-gnu-emacs>,
	<mailto:help-gnu-emacs-request@gnu.org?subject=unsubscribe>
List-Archive: <http://mail.gnu.org/pipermail/help-gnu-emacs>
List-Post: <mailto:help-gnu-emacs@gnu.org>
List-Help: <mailto:help-gnu-emacs-request@gnu.org?subject=help>
List-Subscribe: <http://mail.gnu.org/mailman/listinfo/help-gnu-emacs>,
	<mailto:help-gnu-emacs-request@gnu.org?subject=subscribe>
Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org
Xref: main.gmane.org gmane.emacs.help:15968
X-Report-Spam: http://spam.gmane.org/gmane.emacs.help:15968

Kevin Rodgers <ihs_4664@yahoo.com> writes:

> Jesper Harder wrote:
>
>> I was a bit surprised to see that network data (or any data received
>> from processes) conses Lisp strings.
>>
>> Is it just a quirk of `memory-use-counts' or is it for real?  Why
>> does it need to cons Lisp strings if the data is only inserted in a
>> buffer?
>
> So that the data is available to the process filter?

Right, it would need to cons strings if there are filters.  But it
also happens when there are no filters.

Hmm, I now notice that it also conses cons cells like mad:

(let (m1 process)
    (with-current-buffer (get-buffer-create " *test*")
      (erase-buffer))
    (setq process (open-network-stream "test" " *test*" "news.gmane.org" 119))
    (setq m1 (memory-use-counts))
    (process-send-string process "LIST\n")
    (sit-for 50)
    (process-send-string process "QUIT\n")
    (mapcar* '- (memory-use-counts) m1))

=> (48055 3 0 0 509059 2 0 2063)

(with-current-buffer " *test*" (buffer-size))
=> 252123

Roughly two char-cells for every byte of data received!  That seems
rather excessive ... and I wonder what all those cons cells are used
for.

Emacs 20.5 seems to do _far_ better for the same data (on a faster
network connection, though):

     (4103 0 0 0 4168 0 0)