From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Adam Porter Newsgroups: gmane.emacs.devel Subject: Re: encode-time vs decode-time Date: Mon, 26 Aug 2019 05:59:38 -0500 Message-ID: <87imqkgpk5.fsf@alphapapa.net> References: <502b23f8-58ed-38ff-ae50-fae391129a10@cs.ucla.edu> <87v9viuivo.fsf@mouse.gnus.org> <83blx2cr2o.fsf@gnu.org> <8336iecfvr.fsf@gnu.org> <68d24d6a-d427-baef-27e9-ea1cbbd64c18@cs.ucla.edu> <87sgqd9plt.fsf@mouse.gnus.org> <89271843-6d47-8315-ed9a-540657298985@cs.ucla.edu> <87v9uvmsfa.fsf@mouse.gnus.org> <83af2f70-480b-6e5f-06a5-876224e2b715@cs.ucla.edu> <88b57699-fbdb-bd43-6627-f7491b834955@cs.ucla.edu> <87tvaag54l.fsf@alphapapa.net> <23355b15-fdb2-4f17-8203-82a493ddd3fd@cs.ucla.edu> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="228018"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Aug 26 13:01:12 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1i2CkJ-000x5s-GM for ged-emacs-devel@m.gmane.org; Mon, 26 Aug 2019 13:01:11 +0200 Original-Received: from localhost ([::1]:51710 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1i2CkI-0007Sr-DS for ged-emacs-devel@m.gmane.org; Mon, 26 Aug 2019 07:01:10 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:42770) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1i2Cj4-0007Sg-Re for emacs-devel@gnu.org; Mon, 26 Aug 2019 06:59:56 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1i2Cj3-0002no-Ki for emacs-devel@gnu.org; Mon, 26 Aug 2019 06:59:54 -0400 Original-Received: from 195-159-176-226.customer.powertech.no ([195.159.176.226]:51392 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1i2Cj3-0002nC-Dt for emacs-devel@gnu.org; Mon, 26 Aug 2019 06:59:53 -0400 Original-Received: from list by blaine.gmane.org with local (Exim 4.89) (envelope-from ) id 1i2Cix-000vZY-MY for emacs-devel@gnu.org; Mon, 26 Aug 2019 12:59:47 +0200 X-Injected-Via-Gmane: http://gmane.org/ X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 195.159.176.226 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:239575 Archived-At: Paul Eggert writes: Hi Paul, > I looked briefly at it, and don't see any compatibility issues - not > that I understand all the code, which depends on packages I don't use. Thank you very much for looking at it. > The code's comments say that format-time-string is too slow. What > performance issues did you run into? I didn't necessarily run into problems, but while doing some profiling, I noticed that format-time-string was slower than I expected, so I tried to implement some caching and avoid computing values unnecessarily. You can see some of my primitive test notes, e.g.: https://github.com/alphapapa/ts.el/blob/master/notes.org#accessor-dispatch-vs-string-to-number-format-time-string Some of those benchmarks may be out-of-date with respect to the current code. > At any rate I think you'll find > that this: > > (string-to-number (format-time-string "%Y" (ts-unix struct))) > > is more efficient written this way: > > (nth 5 (decode-time (ts-unix struct))) Thanks, I should have thought of that. > and I expect you can speed up the code further by caching the entire > result of decode-time instead of calling format-time-string for each > component. I do a form of that already in ts-fill by using format-time-string to get all slot values and splitting the resulting string. But that's a good point, I might be able to use decode-time to improve it further. I'll have to do some testing. Thanks. > Also, the timestamp functions in Emacs 27 should simplify ts.el, once > you can assume Emacs 27. For example, in Emacs 27 you can do something > like this: > > (decoded-time-add X (make-decoded-time :year 10)) > > to add 10 years to a broken-down timestamp X. Thanks, I'll have to see if I can make use of those new functions. > One more thing: ts.el's extensive use of float-time is fine for > calendrical applications but has limited resolution (2**-22 s or about > 2e-7 s for today's timestamps) and so would be problematic for apps > requiring higher-resolution timestamps. Right, thanks. My use cases don't involve high-resolution timestamps, so I decided to simplify things by only using Unix timestamp floats. But there is a slot for internal time values, so if that were necessary, the internal implementation could be changed to use them instead. I'm curious, is Emacs fast enough or consistent enough to make use of high-resolution timestamps anyway? I guessed that, with GC pauses, etc., it wouldn't be a suitable platform for such calculations in real-time. Although I guess if the timestamps were from outside Emacs, one could operate on them anyway. Grateful for your feedback!