nash@csli.STANFORD.EDU (Ron Nash) (06/20/88)
As anyone who's tried to write a decent-sized hypercard application knows so well: by the time you build in a reasonable amount of error checking, the whole thing runs so damn slow -- especially a multi-stack program on a Mac+ -- that you wonder whether it's all worthwhile. Version 1.2 adds some functions that make life a good deal easier. (Still, the popup fields in the new release notes stack are disappointingly slow on a Mac+). The point of this posting is to solicit strategies for increasing the efficiency of hypertalk code: algorithms, data structures, stack structures, etc. As someone who occasionally takes on fairly large projects (my last had about 3500 lines of code), I'm looking to get some pointers. But let me start things off with one technique I've found to be a real timesaver. Scenario: a multi-stack program. A handler in stack A accepts some input from the user and goes off to stack B to perform various complicated functions, returning to stack A when done. It turns out that putting the code for these various complicated functions in a handler in stack A is a real time sink. This is painfully obvious when you run the code on a MacII and see hypercard continually flip back and forth between stacks (as evidenced by the changing pathnames in the title bar). The solution is simple, but a major win: put all the code for the complicated functions in stack B, and have the handler in stack A send doComplicatedFunctions to stack B. Stack flipping is reduced to a minimum, and the same functions execute in about 1/10 the time (your mileage may vary). -Ron Nash Center for the Study of Language and Information Stanford University nash@csli.stanford.edu
GFX@PSUVM.BITNET (06/20/88)
In article <4348@csli.STANFORD.EDU>, nash@csli.STANFORD.EDU (Ron Nash) says: > >As anyone who's tried to write a decent-sized hypercard application >knows so well: by the time you build in a reasonable amount of >error checking, the whole thing runs so damn slow -- especially a >multi-stack program on a Mac+ -- that you wonder whether it's all >worthwhile. [...] > I could not agree more with this statement. Now, being a somewhat "naive" user, I often wonders if future releases of Hypercard could generate their own XCMDs, that is, compile those scripts that take forever to execute. Hypercard provides a wonderful front end for week-ends scripters like me, but if you do not fully understand the exquisite architecture of XCMDs, meaningful applications are simply too slow to be useful. For example, I wrote scripts to perform various statistical analyses (variance, correlations, multiple regression, etc.) which reside in the home stack. Would it not be possible for someone to come up with a general XCMD that would transform these scripts in XFCNs? Or could someone tell me why this would not be feasible? For the sake of the discussion, I think that the question must distinguish two kinds of external resources: a) those that rely strictly on HyperText syntax, and whose purpose is to speed things up (Eg SortXFCN could have been written in HyperText), and b) those that expand HyperText (Eg GetCreator, FileNamePlus, etc.) I have the feeling that a program generator for the first type of resources is not beyond the realm of the short term possibilities, while the second (which could compile Pascal code directly into an XCMD-XFCN) may require much more thought and effort. I, for one, know that I would be willing to invest in a program generator of the first kind. Is there someone out there working on that? Is this feasible? ------- Stephane Gauvin : GFX@PSUVM : (814) 237-4979 : Compuserve 73057,1763 Interests: Marketing: New products, Mathematical Models, Game Theory Computing: AI, MacIntosh, Hypercard