* gnus-correct-length vs. string-width @ 2001-12-28 14:26 Jesper Harder 2001-12-28 17:22 ` Simon Josefsson 0 siblings, 1 reply; 7+ messages in thread From: Jesper Harder @ 2001-12-28 14:26 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: gnus-correct-length vs. string-width 2001-12-28 14:26 gnus-correct-length vs. string-width Jesper Harder @ 2001-12-28 17:22 ` Simon Josefsson 2001-12-28 23:24 ` Lars Magne Ingebrigtsen 2001-12-30 1:32 ` Jesper Harder 0 siblings, 2 replies; 7+ messages in thread From: Simon Josefsson @ 2001-12-28 17:22 UTC (permalink / raw) Cc: ding 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) ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: gnus-correct-length vs. string-width 2001-12-28 17:22 ` Simon Josefsson @ 2001-12-28 23:24 ` Lars Magne Ingebrigtsen 2002-01-05 7:00 ` Daniel Pittman 2001-12-30 1:32 ` Jesper Harder 1 sibling, 1 reply; 7+ messages in thread From: Lars Magne Ingebrigtsen @ 2001-12-28 23:24 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: gnus-correct-length vs. string-width 2001-12-28 23:24 ` Lars Magne Ingebrigtsen @ 2002-01-05 7:00 ` Daniel Pittman 2002-01-05 16:08 ` Lars Magne Ingebrigtsen 0 siblings, 1 reply; 7+ messages in thread From: Daniel Pittman @ 2002-01-05 7:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: gnus-correct-length vs. string-width 2002-01-05 7:00 ` Daniel Pittman @ 2002-01-05 16:08 ` Lars Magne Ingebrigtsen 2002-01-06 11:25 ` Daniel Pittman 0 siblings, 1 reply; 7+ messages in thread From: Lars Magne Ingebrigtsen @ 2002-01-05 16:08 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: gnus-correct-length vs. string-width 2002-01-05 16:08 ` Lars Magne Ingebrigtsen @ 2002-01-06 11:25 ` Daniel Pittman 0 siblings, 0 replies; 7+ messages in thread From: Daniel Pittman @ 2002-01-06 11:25 UTC (permalink / raw) 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) ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: gnus-correct-length vs. string-width 2001-12-28 17:22 ` Simon Josefsson 2001-12-28 23:24 ` Lars Magne Ingebrigtsen @ 2001-12-30 1:32 ` Jesper Harder 1 sibling, 0 replies; 7+ messages in thread From: Jesper Harder @ 2001-12-30 1:32 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2002-01-06 11:25 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2001-12-28 14:26 gnus-correct-length vs. string-width Jesper Harder 2001-12-28 17:22 ` Simon Josefsson 2001-12-28 23:24 ` Lars Magne Ingebrigtsen 2002-01-05 7:00 ` Daniel Pittman 2002-01-05 16:08 ` Lars Magne Ingebrigtsen 2002-01-06 11:25 ` Daniel Pittman 2001-12-30 1:32 ` Jesper Harder
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).