Subject: bug#20154: 25.0.50; json-encode-string is too slow for large strings

From: Ivan Shmakov <[email-masked]>
Date: Sun, 22 Mar 2015 16:15:48 +0000

>>>>> Dmitry Gutov <[email-masked]> writes:

 > (defun json-encode-string-3 (string)
 >   "Return a JSON representation of STRING."
 >   (let ((l (length string))
 >         (start 0)
 >         (res (list "\"")))
 >     ;; Skip over ASCIIish printable characters.
 >     (while (string-match "[\"\\/\b\f\n\r\t]\\|[^ -~]" string start)
 >       (let* ((mb (match-beginning 0))

	Why not ‘let’ mb above and use (while (setq mb (string-match …))
	…) here (instead of going through match-beginning)?

 >              (c (aref string mb))
 >              (special (rassoc c json-special-chars)))

	Is there a specific reason to prefer rassoc over rassq here?

 >         (push (substring string start mb) res)
 >         (push (if special
 >                   ;; Special JSON character (\n, \r, etc.).
 >                   (string ?\\ (car special))
 >                 ;; Fallback: UCS code point in \uNNNN form.
 >                 (format "\\u%04x" c))
 >               res)
 >         (setq start (1+ mb))))
 >     (push (substring string start l) res)
 >     (push "\"" res)
 >     (apply #'concat (nreverse res))))

	I guess you can (apply #'concat "\"" (substring …) (nreverse …))
	just as well, instead of pushing to the list just before getting
	rid of it.

[…]

 > Please keep the discussion participants in Cc, even if you prefer not
 > to receive the copy email.

	Curiously, per my experience, the practice of Cc:-ing the
	subscribers tends to be frowned upon when it comes to the lists
	dedicated to free software.  For the reasons I do not know or
	understand, Emacs lists are apparently an exception, though.

	I don’t seem to recall any issues with me trying to stick to the
	custom (of /not/ Cc:-ing) I’ve learned earlier; but if
	necessary, I surely can remember to Cc: those who so request.

-- 
FSF associate member #7257  http://boycottsystemd.org/  … 3013 B6A0 230E 334A