all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* Does network data really cons strings?
@ 2004-01-12 21:41 Jesper Harder
  2004-01-12 22:39 ` Kevin Rodgers
  0 siblings, 1 reply; 4+ messages in thread
From: Jesper Harder @ 2004-01-12 21:41 UTC (permalink / raw)


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?

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Does network data really cons strings?
  2004-01-12 21:41 Does network data really cons strings? Jesper Harder
@ 2004-01-12 22:39 ` Kevin Rodgers
  2004-01-13  3:17   ` Jesper Harder
  0 siblings, 1 reply; 4+ messages in thread
From: Kevin Rodgers @ 2004-01-12 22:39 UTC (permalink / raw)


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?


-- 
Kevin Rodgers

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Does network data really cons strings?
  2004-01-12 22:39 ` Kevin Rodgers
@ 2004-01-13  3:17   ` Jesper Harder
  2004-01-13 16:58     ` Kevin Rodgers
  0 siblings, 1 reply; 4+ messages in thread
From: Jesper Harder @ 2004-01-13  3:17 UTC (permalink / raw)


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)

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Does network data really cons strings?
  2004-01-13  3:17   ` Jesper Harder
@ 2004-01-13 16:58     ` Kevin Rodgers
  0 siblings, 0 replies; 4+ messages in thread
From: Kevin Rodgers @ 2004-01-13 16:58 UTC (permalink / raw)


Jesper Harder wrote:

> 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.


That'd be a nice optimization: don't bother allocating strings for processes

that don't have a filter.


> 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.


Yikes, maybe a bug report is in order...


> 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)


-- 
Kevin Rodgers

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2004-01-13 16:58 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-01-12 21:41 Does network data really cons strings? Jesper Harder
2004-01-12 22:39 ` Kevin Rodgers
2004-01-13  3:17   ` Jesper Harder
2004-01-13 16:58     ` Kevin Rodgers

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.