gnus-correct-length vs. string-width

gnus-correct-length vs. string-width

[Jesper Harder]

Is the built-in function `string-width' known to be broken?

I'm asking because the Gnus substitute `gnus-correct-length' seems to be
horribly expensive in comparison -- it really degrades performance when
generating summary buffers.  Here's the elp results for entering an NNTP
group with 4000 messages:

Function Name                         Call Count  Elapsed Time  Average Time
====================================  ==========  ============  ============
gnus-topic-select-group               1           103.839829    103.839829
gnus-group-select-group               1           103.839535    103.839535
gnus-group-read-group                 1           103.839481    103.839481
gnus-summary-read-group               1           103.839243    103.839243
gnus-summary-read-group-1             1           103.839173    103.839173
gnus-summary-prepare                  1           72.383289     72.383289
gnus-summary-prepare-threads          1           69.354715     69.354715
gnus-correct-length                   16000       39.978197000  0.0024986373

... and the same results after doing:

    (defalias 'gnus-correct-length 'string-width)

Function Name                         Call Count  Elapsed Time  Average Time
====================================  ==========  ============  ============
gnus-topic-select-group               1           66.504824     66.504824
gnus-group-select-group               1           66.50452      66.50452
gnus-group-read-group                 1           66.504463     66.504463
gnus-summary-read-group               1           66.504229     66.504229
gnus-summary-read-group-1             1           66.504158     66.504158
gnus-summary-prepare                  1           34.509797     34.509797
gnus-select-newsgroup                 1           31.573028     31.573028
gnus-summary-prepare-threads          1           31.530489     31.530489
...
gnus-correct-length                   16000       0.2750719999  1.719...e-05


I.e. this is about 35% faster.

Re: gnus-correct-length vs. string-width

[Simon Josefsson]

Jesper Harder <harder@ifa.au.dk> writes:

> Is the built-in function `string-width' known to be broken?

When I try the examples from the original thread
(<87itf461hj.fsf@inanna.rimspace.net> etc) `string-width' works fine.
(format "%-10s" ...) with wide characters still behaves differently
between Emacs and XEmacs though, but that shouldn't matter.

> I'm asking because the Gnus substitute `gnus-correct-length' seems to be
> horribly expensive in comparison -- it really degrades performance when
> generating summary buffers.  Here's the elp results for entering an NNTP
> group with 4000 messages:

Could CJK people please try running with the patch below?

--- gnus-spec.el.~6.27.~	Tue Dec 18 20:42:52 2001
+++ gnus-spec.el	Fri Dec 28 18:21:11 2001
@@ -264,11 +264,7 @@
 	 (insert (make-string (max (- ,(abs column) (current-column)) 0)
 			      ? ))))))
 
-(defun gnus-correct-length (string)
-  "Return the correct width of STRING."
-  (let ((length 0))
-    (mapcar (lambda (char) (incf length (gnus-char-width char))) string)
-    length))
+(defalias gnus-correct-length 'string-width)
 
 (defun gnus-correct-substring (string start &optional end)
   (let ((wstart 0)

Re: gnus-correct-length vs. string-width

[Lars Magne Ingebrigtsen]

Simon Josefsson <jas@extundo.com> writes:

> When I try the examples from the original thread
> (<87itf461hj.fsf@inanna.rimspace.net> etc) `string-width' works fine.
> (format "%-10s" ...) with wide characters still behaves differently
> between Emacs and XEmacs though, but that shouldn't matter.

It seems to work correctly on Emacs 20, 21 and XEmacs 21, so I think
we should probably ditch `gnus-correct-length' and related functions
like `gnus-char-width'.

Or, at the very least, have gnus-ems.el just check whether
`string-width' gives reasonable results, and defalias according to
that.

Unless somebody has a good reason for why we shouldn't do that...

-- 
(domestic pets only, the antidote for overdose, milk.)
   larsi@gnus.org * Lars Magne Ingebrigtsen

Re: gnus-correct-length vs. string-width

[Jesper Harder]

jas@extundo.com (Simon Josefsson) writes:

> Jesper Harder <harder@ifa.au.dk> writes:
>
>> Is the built-in function `string-width' known to be broken?
>
> When I try the examples from the original thread
> (<87itf461hj.fsf@inanna.rimspace.net> etc) 

Thanks for the pointer.  I hadn't noticed that it is customizable with
`gnus-use-correct-string-widths'.  So it's not so bad after all, though
I think nil would maybe be a better default, because it is so slow.

But there still seems to be a bug in the code in
`gnus-parse-simple-format'.  If I set `gnus-use-correct-string-widths'
to nil, `gnus-correct-length' is still used, although less frequently
than before.

Hmm, I don't really understand the code, but AFAICS the problem is the
condition in line 558 (gnus-spec.el):

	  (if (or max-width cut-width ignore-value
		  (and (featurep 'xemacs)
		       gnus-use-correct-string-widths))

which causes `gnus-correct-pad-form' to be used even if
g-u-c-string-widths is nil.

Re: gnus-correct-length vs. string-width

[Daniel Pittman]

On Sat, 29 Dec 2001, Lars Magne Ingebrigtsen wrote:
> Simon Josefsson <jas@extundo.com> writes:
> 
>> When I try the examples from the original thread
>> (<87itf461hj.fsf@inanna.rimspace.net> etc) `string-width' works fine.
>> (format "%-10s" ...) with wide characters still behaves differently
>> between Emacs and XEmacs though, but that shouldn't matter.
> 
> It seems to work correctly on Emacs 20, 21 and XEmacs 21, so I think
> we should probably ditch `gnus-correct-length' and related functions
> like `gnus-char-width'.
> 
> Or, at the very least, have gnus-ems.el just check whether
> `string-width' gives reasonable results, and defalias according to
> that.
> 
> Unless somebody has a good reason for why we shouldn't do that...

(format "%-10s" ...) differs on character vs byte width between XEmacs
and GNU Emacs. This means that the "correct" width is lost when doing
cut operations on wide characters in the summary buffer...

...so, feel free to fix it, but if I start getting the wrong results I
will submit a patch to make it work again.

It's only really the `format' stuff that's different between the two
Emacs-en, IIRC, but I have not thought about this for ages...

        Daniel

-- 
If there really is a God who created the entire universe with all of its
glories, and He decides to deliver a message to humanity, He will not use, as
His messenger, a person on cable TV with a bad hairstyle.
        -- Dave Barry

Re: gnus-correct-length vs. string-width

[Lars Magne Ingebrigtsen]

Daniel Pittman <daniel@rimspace.net> writes:

> (format "%-10s" ...) differs on character vs byte width between XEmacs
> and GNU Emacs. This means that the "correct" width is lost when doing
> cut operations on wide characters in the summary buffer...

Ah, right; that was it.

But we could alias those functions to the built-in functions on
Emacsen that give us the results we want.

This is under XEmacs:

(string-width (format "%10s" "你好"))
=> 12

And this is under Emacs:

(string-width (format "%10s" "你好"))
=> 10

So how about if we just default `gnus-use-correct-string-widths' to
`(featurep 'xemacs)'?

-- 
(domestic pets only, the antidote for overdose, milk.)
   larsi@gnus.org * Lars Magne Ingebrigtsen

Re: gnus-correct-length vs. string-width

[Daniel Pittman]

On Sat, 05 Jan 2002, Lars Magne Ingebrigtsen wrote:
> Daniel Pittman <daniel@rimspace.net> writes:
> 
>> (format "%-10s" ...) differs on character vs byte width between
>> XEmacs and GNU Emacs. This means that the "correct" width is lost
>> when doing cut operations on wide characters in the summary buffer...
> 
> Ah, right; that was it.
> 
> But we could alias those functions to the built-in functions on
> Emacsen that give us the results we want.

[...]

> So how about if we just default `gnus-use-correct-string-widths' to
> `(featurep 'xemacs)'?

Fine by me. I suggest keeping it active by default, though, for that
branch.

        Daniel

-- 
There is censorship in this country, all right, make no mistake about that,
but also make no mistake about its source...While the government will not
censor, apparently the networks will. The irreparable damage to the public is
all the same.
        -- Nicholas Johnson, Federal Communications Commissioner,
           _New York Times_, (April 8, 1969)