X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["1288" "Thu" "13" "August" "1998" "15:20:22" "+0200" "Hans Aberg" "haberg@MATEMATIK.SU.SE" nil "24" "Re: Space and Time" "^Date:" nil nil "8" nil "Space and Time" nil nil nil] nil) Received: from listserv.gmd.de (listserv.gmd.de [192.88.97.1]) by mail.Uni-Mainz.DE (8.8.8/8.8.8) with ESMTP id PAA24810; Thu, 13 Aug 1998 15:22:20 +0200 (MET DST) Received: from lsv1.listserv.gmd.de (192.88.97.2) by listserv.gmd.de (LSMTP for OpenVMS v1.1a) with SMTP id <3.9FED2674@listserv.gmd.de>; Thu, 13 Aug 1998 15:22:19 +0200 Received: from RELAY.URZ.UNI-HEIDELBERG.DE by RELAY.URZ.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 1.8b) with spool id 395507 for LATEX-L@RELAY.URZ.UNI-HEIDELBERG.DE; Thu, 13 Aug 1998 15:22:12 +0200 Received: from mail.nada.kth.se (root@mail.nada.kth.se [130.237.222.92]) by relay.urz.uni-heidelberg.de (8.8.8/8.8.8) with ESMTP id PAA29737 for ; Thu, 13 Aug 1998 15:22:09 +0200 (MET DST) Received: from [130.237.37.42] (sl22.modempool.kth.se [130.237.37.42]) by mail.nada.kth.se (8.8.7/8.8.7) with ESMTP id PAA28677 for ; Thu, 13 Aug 1998 15:22:08 +0200 (MET DST) X-Sender: su95-hab@mail.nada.kth.se (Unverified) References: <199808122232.PAA05747@math.uci.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: Reply-To: Mailing list for the LaTeX3 project In-Reply-To: <199808130031.UAA09112@mail-out-3.tiac.net> Date: Thu, 13 Aug 1998 15:20:22 +0200 From: Hans Aberg Sender: Mailing list for the LaTeX3 project To: Multiple recipients of list LATEX-L Subject: Re: Space and Time Status: R X-Status: X-Keywords: X-UID: 2677 I have spent some time thinking about optimizations in a C++ program I write, like when implementing conservative GC (garbage collectors) and the like: On this very low level, one must think very hard on whether can allow an increment like "count++", and the like, because it happens every time an object is called. So, I think optimizations will never be out of the question: When computers become more powerful, the first optimization is for time. In addition, the places that need the most optimizations are often only a few places with code that is called often. With TeX, if long names decrease speed, the should only be used at places that are not called to often. Similarly all macro expansions that can be avoided should be avoided in code that is called often. However, with code that is more high level, and is not called so often, the opposite often happens: One should indeed put in extra macro expansions and the like, if that can help describing the programming structures: This will help making the code safer and also cutting developing time. Hans Aberg * Email: Hans Aberg * Home Page: * AMS member listing: