Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!decwrl!bacchus.pa.dec.com!granite.pa.dec.com!mwm From: mwm@raven.pa.dec.com (Mike (Real Amigas have keyboard garages) Meyer) Newsgroups: comp.lang.rexx Subject: Re: Rexx compiler(s) Message-ID: Date: 27 Aug 90 19:27:06 GMT References: <90230.092947BOYDJ@QUCDN.BITNET> <90231.095318BOYDJ@QUCDN.BITNET> <26d00a0a-3d.4comp.lang.rexx-1@tronsbox.xei.com> <90234.100626RMCCU@CUNYVM.BITNET> <90235.100535MADIF@ROHVM1.BITNET> Sender: news@wrl.dec.com (News) Organization: Missionaria Phonibalonica Lines: 26 In-Reply-To: MADIF@ROHVM1.BITNET's message of 23 Aug 90 14:05:35 GMT In article <90235.100535MADIF@ROHVM1.BITNET> MADIF@ROHVM1.BITNET (Jim Foster) writes: Oh? What if you've got a 50,000 line REXX application that "yearns for speed"? How long would it take to re-write it in assembler verses running it through the compiler? While I agree with you that a complete compiler would be nice, that question begs for a good answer. To wit: Years if you do it wrong, weeks if you do it right. Doing it right means running it through a profiler (you mean you don't have a Rexx profiler? You should fix that!), and fixing the small part of it that is actually time-critical. There's a small chance there aren't any such hot spots, but chances are very good it's only a couple of percent of the code. Even then, the best fix is to examine the hot-spots and rewrite them using faster algorithms. If that doesn't work, you specify the command that would make it fastest, and have that part written in (choose your favorite compiled language). Ideally, that language would be Rexx, but...