[M3commit] CVS Update: cm3

[Jay K]

Blech, looking at the change: 
Generally size optimizations beat speed optimizations.
Those lookup tables are wasteful. And tedious to read/write
for a human, vs., the clear compact logic I put in.And as I said, division/mod by a constant is efficient, at least on 32bit systems with 64bit operations.Hm. I tried 64bit div and that was still optimized into a multiplication.The code size for that is going to be much smaller than the tables.And the affects on cache probably better too.
 Generally I find "if (variable relation constant)"
easier to read than "if (constant relation variable)".
I understand the isomorphisms, but it is still more
usual to state the first. 
2K is a pretty small buffer size these days.
Even 64K that I chose is small.
 Yes I know I'm arguing both sides of size here.
One is code size, the other is buffer size.
 Integer to text has been implemented countless times.
I suspect my way with one table is way more common
than your way with three tables. 
 - Jay



 > Date: Tue, 4 Sep 2012 16:43:27 +0000
> To: m3commit at elegosoft.com
> From: hosking at elego.de
> Subject: [M3commit] CVS Update: cm3
> 
> CVSROOT:	/usr/cvs
> Changes by:	hosking at birch.	12/09/04 16:43:27
> 
> Modified files:
> 	cm3/m3-sys/m3middle/src/: M3Buf.m3 
> 
> Log message:
> 	ChunkSize was exposed elsewhere.  I agree with Jay that it may be better to be
> 	consistent, but leave the rest as was for efficiency.
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3commit/attachments/20120912/4cd6e4f8/attachment-0002.html>