Gordon, Beware that even i surprise myself with newby tricks.
I just posted a "slow" fractal moire maker. It creates beautiful patterns and the detail is amazing but it does so creating some 40000 graphics in a card. For the truely beautiful patterns, it took 300000 graphics! The making can still be optimized but deleting images cannot be done like words in a field! Delete graphic 1 to -1 or delete all graphics doesn't work. i have the patience to create these graphics and see them rendered. But when it comes to getting rid of them, no way! And the clearGraphics routine took foreever! 200 graphics per second... You do the math - many minutes wasted waiting to create a better pattern. The trick was to create all the graphics in a group. when the graphic is done, delete the group. 300000 graphics deleted in 2 seconds. Hope this brings insight... Rev does wonders you wouldn't believe - and C optimization is not always the trick - the objects are not the same when it comes to the GUI. But when it comes to doing many of many things in a script that's where it starts showing... Like i said, there's always another way to do it! cheers Xav > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Gordon Webster > Sent: Wednesday, June 22, 2005 16:14 > To: How to use Revolution > Subject: Re: compileIt for revolution? > > I would absolutely echo what Dennis has just said. I was > initially really impressed with rev and I should say I still > am in certain respects - comfort and ease of use, the elegant > and intuitive language and stack/card paradigm etc. etc. > > But I have been unable to get rev to do what I want it to do > behind the scenes (i.e. my application logic) without jumping > through the kinds of hoops that Dennis describes - > effectively negating all the advantages of programming in > Transcript that I just outlined. > > And even when I could get the code working, man it was SLOW. > It was discouraging to see Python easily outrun rev for the > equivalent code - I mean I love Python and all, but it's > hardly the gold standard for speed. > > I would think that the stack paradigm would neatly allow for > the creation of strongly-typed stacks that could be jumped > into from the kind of warm and fuzzy typeless stacks that > give rev its wonderful flexibility. The compiler could then > insist on declarations for all objects within the typed stack > and compile it with far greater optimization than is possible > for the typeless stacks, perhaps even going as far as native > code compilation :-D > > Imagine what a superb development environment rev could be > with these features. Flexible and typeless for all the > UI/scripty/fun parts of the app; more draconian but hellishly > fast for the down-to-the-metal hardcore byte-crunching parts > of the app. Strong typing would probably also make it a lot > easier to automate the process of calling externals from > Transcript without all those ghastly, clunky C wrappers and crap. > > There's a dream - a rev scientific application with a > beautiful interface rendering OpenGL objects in real time and > a typed, Transcript-coded stack running energy minimization > on a separate thread in the background. > > I doubt I'll put my hands in my pockets again and upgrade my > expired rev license just to have "deep masks" on my GUIs - > I'm not knocking it, it's just not a feature I urgently need > right now ... but fast compiled stacks, easy access to > externals ... now you're talking ... where's my check book? > > Best > > Gordon > > --- Dennis Brown <[EMAIL PROTECTED]> wrote: > > > Dan, > > > > I also would like to speed up array processing. It kills > me that my > > friend won't move from VB to Rev because when I write the > same array > > processing problem that he uses, VB runs 10+ times > > faster than Rev. > > I also have had to jump through hoops trying to figure out ways to > > make my array processing go faster --it usually requires taking a > > simple script and making it 5 times as complicated as the way you > > would do it in VB or RB or any other ordinary language. It is not > > just for the type of math problems that I am dealing with. > As visual > > effects become more important, being able to quickly > process numeric > > arrays like a pixel image array becomes important. > > > > However, I don't think compiling scripts is the answer. I > love having > > the interpreted environment for interactive debug and > experimentation. > > The UI is where all the code and debugging time is spent. I don't > > want to trade that in for anything. > > Rev is all about > > UI, but weak on array speed. The language as it is > > defined would > > hardly be faster as a compiled version because of the type-less and > > stringy nature of the variables. Compiled languages get their > > effeciency by the programmer telling them up front the data > type and > > therefore the correspondence to specific machine > > code operators. > > There is no guessing or mixing of types. The processing of numeric > > (or fixed length strings) hardly needs any checks at runtime. > > > > What I advocate is a cross platform runtime package that is a pure > > fixed type, fixed operator, math orientated array language. > It can be > > PCode or threaded with very low overhead. > > Languages with no UI > > considerations are very easy to create and code for a machine code > > programmer. I would like to see the basic operators and control > > structures to work on regular arrays of n dimensions. I am not > > actually referring to "array" operators, just the ability to apply > > ordinary operators to one addressable array element at a time with > > efficient looping structures. That should result in an order of > > magnitude increase in speed for the stuff that bogs Rev > down, and open > > up Rev as a universal development tool. > > > > The key is to have an efficient and elegant way for Rev to interface > > with such a package. It needs to be able to pass > > the "program code" > > and pass array elements, rows, columns, and whole arrays to the > > coprocessor (really it just needs to be able to pass > pointers to the > > array memory blocks). > > > > As long as Rev has this Achilles heel, it will preclude > it's use as a > > "real" programming language in the minds of many. > > > > I did make a BZ enhancement request, but I think it could > benefit from > > a discussion on this list. > > > > Dennis > > > > > > On Jun 22, 2005, at 1:27 AM, Dan Shafer wrote: > > > > > Xavier.... > > > > > > I guess we'll just have to agree to disagree about > > this. > > > > > > How in the world would you expect a compiled > > script or handler -- > > > if such a thing were possible -- to then be > > smoothly integrated > > > into a stand-alone app? > > > > > > We needed CompileIt! in HyperCard *far* less for > > performance than > > > for code protection and the ability to deliver > > stuff that didn't > > > require the player to be around. Neither of those > > is an issue today > > > in Revolution. > > > > > > As for performance, tuning for such situations has > > produced > > > staggering results. I was blown away in Monterey > > last weekend to > > > watch a dynamically populated menu that was > > pulling its contents > > > from 100 text files appear in under a second. I've > > never heard much > > > here in the way of complaints about slow programs > > written in Rev. > > > > > > Dan > > > > > > On Jun 21, 2005, at 9:31 PM, MisterX wrote: > > > > > > > > >> Dan, > > >> > > >> Creating apps with rev has NOTHING to do with > > compileIt. > > >> > > >> I really would like to speed up some scripts to > > manipulate > > >> arrays (where rev has some serious limitations) > > and the best > > >> possible way to do that would be to have > > something like > > >> CompileIt. > > >> > > > > _______________________________________________ > > use-revolution mailing list > > use-revolution@lists.runrev.com > > Please visit this url to subscribe, unsubscribe and manage your > > subscription preferences: > > > http://lists.runrev.com/mailman/listinfo/use-revolution > > > > _______________________________________________ > use-revolution mailing list > use-revolution@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage > your subscription preferences: > http://lists.runrev.com/mailman/listinfo/use-revolution > _______________________________________________ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
