unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#15149: 24.3; [PATCH] compute calendar-chinese-year-cache lazily
@ 2013-08-21  5:23 Leo Liu
  2013-08-21 16:04 ` Glenn Morris
  0 siblings, 1 reply; 3+ messages in thread
From: Leo Liu @ 2013-08-21  5:23 UTC (permalink / raw)
  To: 15149

[-- Attachment #1: Type: text/plain, Size: 167 bytes --]

Seems a lot of hassle to manually maintain a cache and the computation
is reasonable fast (it takes 0.5 seconds on my Core 2 Duo 2G laptop). So
I propose this patch.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: cal-china.diff --]
[-- Type: text/x-patch, Size: 6387 bytes --]

=== modified file 'lisp/calendar/cal-china.el'
--- lisp/calendar/cal-china.el	2013-01-01 09:11:05 +0000
+++ lisp/calendar/cal-china.el	2013-08-21 05:18:14 +0000
@@ -39,10 +39,6 @@
 ;; not accepted by all authorities.  The date of Chinese New Year is
 ;; correct from 1644-2051.
 
-;; Note to maintainers:
-;; Use `chinese-year-cache-init' every few years to recenter the default
-;; value of `chinese-year-cache'.
-
 ;;; Code:
 
 (require 'calendar)
@@ -324,61 +320,9 @@
                   ;; Second month on list is not a leap month.
                   (calendar-chinese-number-months (cdr list) 1)))))))
 
-(defvar calendar-chinese-year-cache
-  ;; Maintainers: delete existing value, position point at start of
-  ;; empty line, then call  M-: (calendar-chinese-year-cache-init N)
-  '((2000 (12 730126) (1 730155) (2 730185) (3 730215) (4 730244) (5 730273)
-          (6 730303) (7 730332) (8 730361) (9 730391) (10 730420) (11 730450))
-    (2001 (12 730480) (1 730509) (2 730539) (3 730569) (4 730598) (4.5 730628)
-          (5 730657) (6 730687) (7 730716) (8 730745) (9 730775) (10 730804)
-          (11 730834))
-    (2002 (12 730863) (1 730893) (2 730923) (3 730953) (4 730982) (5 731012)
-          (6 731041) (7 731071) (8 731100) (9 731129) (10 731159) (11 731188))
-    (2003 (12 731218) (1 731247) (2 731277) (3 731307) (4 731336) (5 731366)
-          (6 731396) (7 731425) (8 731455) (9 731484) (10 731513) (11 731543))
-    (2004 (12 731572) (1 731602) (2 731631) (2.5 731661) (3 731690) (4 731720)
-          (5 731750) (6 731779) (7 731809) (8 731838) (9 731868) (10 731897)
-          (11 731927))
-    (2005 (12 731956) (1 731986) (2 732015) (3 732045) (4 732074) (5 732104)
-          (6 732133) (7 732163) (8 732193) (9 732222) (10 732252) (11 732281))
-    (2006 (12 732311) (1 732340) (2 732370) (3 732399) (4 732429) (5 732458)
-          (6 732488) (7 732517) (7.5 732547) (8 732576) (9 732606) (10 732636)
-          (11 732665))
-    (2007 (12 732695) (1 732725) (2 732754) (3 732783) (4 732813) (5 732842)
-          (6 732871) (7 732901) (8 732930) (9 732960) (10 732990) (11 733020))
-    (2008 (12 733049) (1 733079) (2 733109) (3 733138) (4 733167) (5 733197)
-          (6 733226) (7 733255) (8 733285) (9 733314) (10 733344) (11 733374))
-    (2009 (12 733403) (1 733433) (2 733463) (3 733493) (4 733522) (5 733551)
-          (5.5 733581) (6 733610) (7 733639) (8 733669) (9 733698) (10 733728)
-          (11 733757))
-    (2010 (12 733787) (1 733817) (2 733847) (3 733876) (4 733906) (5 733935)
-          (6 733965) (7 733994) (8 734023) (9 734053) (10 734082) (11 734112))
-    (2011 (12 734141) (1 734171) (2 734201) (3 734230) (4 734260) (5 734290)
-          (6 734319) (7 734349) (8 734378) (9 734407) (10 734437) (11 734466))
-    (2012 (12 734496) (1 734525) (2 734555) (3 734584) (4 734614) (4.5 734644)
-          (5 734673) (6 734703) (7 734732) (8 734762) (9 734791) (10 734821)
-          (11 734850))
-    (2013 (12 734880) (1 734909) (2 734939) (3 734968) (4 734998) (5 735027)
-          (6 735057) (7 735087) (8 735116) (9 735146) (10 735175) (11 735205))
-    (2014 (12 735234) (1 735264) (2 735293) (3 735323) (4 735352) (5 735382)
-          (6 735411) (7 735441) (8 735470) (9 735500) (9.5 735530) (10 735559)
-          (11 735589))
-    (2015 (12 735618) (1 735648) (2 735677) (3 735707) (4 735736) (5 735765)
-          (6 735795) (7 735824) (8 735854) (9 735884) (10 735914) (11 735943))
-    (2016 (12 735973) (1 736002) (2 736032) (3 736061) (4 736091) (5 736120)
-          (6 736149) (7 736179) (8 736208) (9 736238) (10 736268) (11 736297))
-    (2017 (12 736327) (1 736357) (2 736386) (3 736416) (4 736445) (5 736475)
-          (6 736504) (6.5 736533) (7 736563) (8 736592) (9 736622) (10 736651)
-          (11 736681))
-    (2018 (12 736711) (1 736741) (2 736770) (3 736800) (4 736829) (5 736859)
-          (6 736888) (7 736917) (8 736947) (9 736976) (10 737006) (11 737035))
-    (2019 (12 737065) (1 737095) (2 737125) (3 737154) (4 737184) (5 737213)
-          (6 737243) (7 737272) (8 737301) (9 737331) (10 737360) (11 737389))
-    (2020 (12 737419) (1 737449) (2 737478) (3 737508) (4 737538) (4.5 737568)
-          (5 737597) (6 737627) (7 737656) (8 737685) (9 737715) (10 737744)
-          (11 737774)))
+(defvar calendar-chinese-year-cache nil
   "Alist of Chinese year structures as determined by `chinese-year'.
-The default can be nil, but some values are precomputed for efficiency.")
+The default is nil but some values are lazily computed for efficiency.")
 
 (defun calendar-chinese-year (y)
   "The structure of the Chinese year for Gregorian year Y.
@@ -386,6 +330,12 @@
 of the Chinese months from the Chinese month following the solstice in
 Gregorian year Y-1 to the Chinese month of the solstice of Gregorian year Y.
 The list is cached in `calendar-chinese-year-cache' for further use."
+  (or calendar-chinese-year-cache
+      (setq calendar-chinese-year-cache
+            (mapcar (lambda (y)
+                      (cons y (calendar-chinese-compute-year y)))
+                    (let ((year (nth 5 (decode-time))))
+                      (number-sequence (- year 10) (+ year 10))))))
   (let ((list (cdr (assoc y calendar-chinese-year-cache))))
     (or list
         (setq list (calendar-chinese-compute-year y)
@@ -393,28 +343,6 @@
                                          (list (cons y list)))))
     list))
 
-;; Maintainer use.
-(defun calendar-chinese-year-cache-init (year)
-  "Insert an initialization value for `calendar-chinese-year-cache' after point.
-Computes values for 10 years either side of YEAR."
-  (setq year (- year 10))
-  (let (calendar-chinese-year-cache end)
-    (save-excursion
-      (insert "'(")
-      (dotimes (n 21)
-        (princ (cons year (calendar-chinese-compute-year year))
-               (current-buffer))
-        (insert (if (= n 20) ")" "\n"))
-        (setq year (1+ year)))
-      (setq end (point)))
-    (save-excursion
-      ;; fill-column -/+ 5.
-      (while (and (< (point) end)
-                  (re-search-forward "^.\\{65,75\\})" end t))
-        (delete-char 1)
-        (insert "\n")))
-    (indent-region (point) end)))
-
 (defun calendar-chinese-to-absolute (date)
   "The number of days elapsed between the Gregorian date 12/31/1 BC and DATE.
 DATE is a Chinese date (cycle year month day).  The Gregorian date


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

* bug#15149: 24.3; [PATCH] compute calendar-chinese-year-cache lazily
  2013-08-21  5:23 bug#15149: 24.3; [PATCH] compute calendar-chinese-year-cache lazily Leo Liu
@ 2013-08-21 16:04 ` Glenn Morris
  2013-08-22  4:48   ` Leo Liu
  0 siblings, 1 reply; 3+ messages in thread
From: Glenn Morris @ 2013-08-21 16:04 UTC (permalink / raw)
  To: Leo Liu; +Cc: 15149

Leo Liu wrote:

> Seems a lot of hassle to manually maintain a cache 

It's been no hassle.

> and the computation is reasonable fast (it takes 0.5 seconds on my
> Core 2 Duo 2G laptop). So I propose this patch.

Probably precomputing serves little purpose in this day and age, and
could just as well be removed. But since it is causing no problems, I
don't see too much point.

>  (defun calendar-chinese-year (y)
>    "The structure of the Chinese year for Gregorian year Y.
> @@ -386,6 +330,12 @@
>  of the Chinese months from the Chinese month following the solstice in
>  Gregorian year Y-1 to the Chinese month of the solstice of Gregorian year Y.
>  The list is cached in `calendar-chinese-year-cache' for further use."
> +  (or calendar-chinese-year-cache
> +      (setq calendar-chinese-year-cache
> +            (mapcar (lambda (y)
> +                      (cons y (calendar-chinese-compute-year y)))
> +                    (let ((year (nth 5 (decode-time))))
> +                      (number-sequence (- year 10) (+ year 10))))))

I don't see the point of this. It makes the first call you make ~ 20
times slower, in order to compute a bunch of values that might well have
no relevance to that call or any other.





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

* bug#15149: 24.3; [PATCH] compute calendar-chinese-year-cache lazily
  2013-08-21 16:04 ` Glenn Morris
@ 2013-08-22  4:48   ` Leo Liu
  0 siblings, 0 replies; 3+ messages in thread
From: Leo Liu @ 2013-08-22  4:48 UTC (permalink / raw)
  To: Glenn Morris; +Cc: 15149

On 2013-08-22 00:04 +0800, Glenn Morris wrote:
> I don't see the point of this. It makes the first call you make ~ 20
> times slower, in order to compute a bunch of values that might well have
> no relevance to that call or any other.

OK. Feel free to close this bug.

Leo





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

end of thread, other threads:[~2013-08-22  4:48 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-08-21  5:23 bug#15149: 24.3; [PATCH] compute calendar-chinese-year-cache lazily Leo Liu
2013-08-21 16:04 ` Glenn Morris
2013-08-22  4:48   ` Leo Liu

Code repositories for project(s) associated with this public inbox

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

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 read-only IMAP folder(s) and NNTP newsgroup(s).