cs450a03@uc780.umd.edu (03/27/91)
J is slower than I think it should be (Obviously a world shaking problem 8-) There are a couple techniques for speeding up code which I think might be applicable here. (1) moving code which computes "constants" outside of loops. (2) using simpler functions where applicable. If I were working on the language itself, I might try implementing (1) by designing all of the primitives to handle data of rank (1+advertised rank). (Thus duplicating some of the code for " a number of times). I think this would allow you to cut a lot of the type checking overhead. And, I'd try implementing (2) by choosing 1 case which I felt common for each function (say, multiplying by a boolean, or modulo by a power of 2) and try and optimize for that specific case. But I'm not working on the interpreter... So, (1) can still be implented by writing so as to minimize the number of function calls. (For each application of a function, you seem to get 1 fn call for each array cell. Calls to derived functions imply m calls for each application of the derived function.) In other words, do not modularize at a low level. In my example of uuencode, cutting out the "uul" function, and writing the whole thing as a single transformation (then sticking on delimiters, and so on...) seems to speed things up a bit. And (2), I guess, simply requires a fair amount of experimentation. (For example, for uuencode, I ought to try using a table lookup to convert from ascii numerics to binary). Any other thoughts on this subject? Raul Rockwell