Re: Speed differences between MC and Rev (problem area nearly found)
Richard, Your guess about memory just might be a good one. I had to quit using Constellation when building ButtonGadget2 because it was clear there were memory errors involved after compositing, which also used imagedata and alphadata calls quite a lot. After a few composites with Constellation open, things just got weird and the compositing sooner or later quit working. As soon as I closed Constellation and removed from memory, things started working again. Jerry assured me he did nothing with imagedata calls or traps. One of the reasons to this day I try and keep all plugins (including my own) closed unless I have to use them. My guess is there is a memory issue at play here, which is always difficult to diagnose. Wilhelm, your tests are great! Please if you haven't already, test in standalones as well. Just create a standalone launcher app, which auto-launches the stack in the same folder. One for Rev and one for MC and see if the speed differences occur in standalones as well. Perhaps you've already done this and I've missed it somewhere? Good stuff. -Chipp ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: Speed differences between MC and Rev (problem area nearly found)
On Thu, 12 Oct 2006, Richard Gaskin wrote: 12:52:22 -0700 I'm wondering if it isn't script execution at all, but perhaps memory. I can't think of any way your script could be affected by the mere existence of other scripts, since your main handler is pretty well self-contained (so send or other such things which might give RR's scripts some chance to intercede). I don't believe that the scripts RR's standalone maker insists on adding to one's project are all that large, but perhaps in an intensive environment such as your image processing script requires the difference may be just enough to affect performance. How much RAM is installed on your machine? I'm grasping at straws here, but this is such an unexpected result that as far as causes go it may be worth remaining open to possibilities which may even seem unlikely. -- Richard Gaskin and on Fri, 13 Oct 2006 Chipp Walters wrote: Richard, Your guess about memory just might be a good one. (snip) My guess is there is a memory issue at play here, which is always difficult to diagnose. Wilhelm, your tests are great! Please if you haven't already, test in standalones as well. Just create a standalone launcher app, which auto-launches the stack in the same folder. One for Rev and one for MC and see if the speed differences occur in standalones as well. Perhaps you've already done this and I've missed it somewhere? Good stuff. -Chipp Rchard and Chipp, thanks for the responses. I did test with standalones (see the first line of my previous post: In the meantime I did further tests and built standalones for MC 2.6.5, 2.73, 2.74 and Rev 2.6.1, 2.73, 2.74. I tested 3 more scripts and also tested all scripts with a much larger image of 1600 X 1200.), which however could be easily overlooked among the amount of information provided. I do not think memory could be an issue here. The computer I used for testing has 1 GB RAM. The Revolution IDE surely is more of a memory hog, but the measured performance differences between MC and Rev remain about (almost exactly) the same even when comparing the standalones built with the same engine. Following my fresh insight that imagedata handling is the main issue here, I changed the positions of lines put the milliseconds to *after* getting the imagedata and *before* setting the imagedata again at the end of the script: - old script: put the milliseconds into Start put the imageData of image 1 into iData put 0 into counter repeat for each char C in idata add 1 to counter put chartonum(C) into tC put 2* tC into tC if tC 255 then put 255 -tc into tC put numtochar(tC) into char counter of idata end repeat set the imageData of image 1 to iData put the milliseconds - Start into fld test - new script (I am referring to this as measured inside in the following text) put the imageData of image 1 into iData put the milliseconds into Start put 0 into counter repeat for each char C in idata add 1 to counter put chartonum(C) into tC put 2* tC into tC if tC 255 then put 255 -tc into tC put numtochar(tC) into char counter of idata end repeat put the milliseconds - Start into fld test set the imageData of image 1 to iData. I tested these two scripts in versions 2.6.6 and 2.7.4 of Metacard and the corresponding engine versions of Rev 2.6.1 and 2.7.4, both as stacks and as standalones. The stacks were always launched from the same folder. I again used a larger image of 1600 X 1200 which was reset each time immediately after each run of a script. Results (average numbers are given for several measurements in all categories): - MC 2.6.6: Measured inside is 300 milliseconds faster, both in the stack and the standalone (9350 vs. 9050) - Rev 2.6.1 (engine identical to MC 2.6.6) Stack: measured inside is 3400 milliseconds faster (13200 vs. 9800) Standalone: measured inside is 3500 milliseconds faster (12250 vs. 9050) There is another difference here between standalone and stack in REV 2.6.1 indicating an additional interference from the IDE of about 1 second. - MC 2.7.4 Stack: Measured inside is 300 milliseconds faster (9400 vs. 9100) Standalone: Measured inside is also 300 milliseconds faster (9480 vs. 9180), but the standalone is slightly slower than the stack ?? - Rev 2.7.4 Stack: Measured inside is 3130 milliseconds faster (12860 vs. 9730) Standalone: Measured inside is is 3200 milliseconds faster (12400 vs. 9200), and the standalone is somewhat faster than the stack. As you can see when you compare the above data of MC 2.7.4 and Rev 2.7.4 there is an additional speed difference between the IDEs even when measured inside: Rev is here an extra 630 milliseconds slower, meaning that this difference cannot be accounted for by imagedata handling, but must be caused by other interfering scripts in the Rev IDE. Overall conclusion: Rev is generally 3 seconds slower (33 %) when the imagedata handling is included
Re: Speed differences between MC and Rev (problem area nearly found)
Wilhelm Sanke wrote: I tested these two scripts in versions 2.6.6 and 2.7.4 of Metacard and the corresponding engine versions of Rev 2.6.1 and 2.7.4, both as stacks and as standalones. The stacks were always launched from the same folder. I again used a larger image of 1600 X 1200 which was reset each time immediately after each run of a script. Results (average numbers are given for several measurements in all categories): - MC 2.6.6: Measured inside is 300 milliseconds faster, both in the stack and the standalone (9350 vs. 9050) - Rev 2.6.1 (engine identical to MC 2.6.6) Stack: measured inside is 3400 milliseconds faster (13200 vs. 9800) Standalone: measured inside is 3500 milliseconds faster (12250 vs. 9050) There is another difference here between standalone and stack in REV 2.6.1 indicating an additional interference from the IDE of about 1 second. - MC 2.7.4 Stack: Measured inside is 300 milliseconds faster (9400 vs. 9100) Standalone: Measured inside is also 300 milliseconds faster (9480 vs. 9180), but the standalone is slightly slower than the stack ?? - Rev 2.7.4 Stack: Measured inside is 3130 milliseconds faster (12860 vs. 9730) Standalone: Measured inside is is 3200 milliseconds faster (12400 vs. 9200), and the standalone is somewhat faster than the stack. As you can see when you compare the above data of MC 2.7.4 and Rev 2.7.4 there is an additional speed difference between the IDEs even when measured inside: Rev is here an extra 630 milliseconds slower, meaning that this difference cannot be accounted for by imagedata handling, but must be caused by other interfering scripts in the Rev IDE. Overall conclusion: Rev is generally 3 seconds slower (33 %) when the imagedata handling is included in the measurement. There is also an additional interference from the Rev IDE. Damn but that's thorough. Great work. Please make sure you include those in the BZ report. On further consideration, I share your hunch that it isn't related to memory. I ran the same test with Activity Monitor set to display memory usage, and it nowhere near spiked. Given the low frequency with which AM updates that may not be precise, but I have enough memory free that I doubt that's the issue. To verify that the Rev scripts are the cause, one way would be to include an initialization which purges all frontscripts and backscripts. If it ain't in the message path it can't be triggered. But still that leaves us with the core question of how any script could be triggered from within the tight loop of your relatively small handler. In my understanding, revCommon is a backscript only, and the only system message it traps is mouseDoubleUp (not sure why this isn't in the frontScript, but that's for another exploration). Everything else in revCommon is inert in any standalone that doesn't explicitly call those handlers. Given what we know thus far, I'm wondering now if perhaps you've discovered some undocumented feature in the engine which forks execution depending on whether or not revCommon is present. Verifying that would mean going back to v2.5 to test, and it's such a hair-brained idea that it's not likely what's really happening anyway. I mention it only because frankly I'm out of other ideas on what could be going on. For the moment it may be most productive to just post your test and results to BZ and let the folks at RunRev sort it out. As MC users we're unaffected by this performance loss, and no one would benefit more from pinning this down than the folks who have access to the source and are therefore better equipped to delve into the inner workings of what's going on. -- Richard Gaskin Managing Editor, revJournal ___ Rev tips, tutorials and more: http://www.revJournal.com ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: Speed differences between MC and Rev (problem area nearly found)
I still think it could be some sort of memory management error inside the engine. Not necessarily a memory leak (which would show up inside Richard's test), but other problem. Else, why would Constellation work for a little bit, then quit working? In anycase, great work Wilhelm! best, Chipp ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: Speed differences between MC and Rev (problem area nearly found)
Richard Gaskin wrote: Confirmed in the IDEs -- 5740ms/avg in MC, 6830ms/avg in Rev (I have a 1GHz PB G4). I haven't built standalones, though, which would be good to test. In the meantime I did further tests and built standalones for MC 2.6.5, 2.73, 2.74 and Rev 2.6.1, 2.73, 2.74. I tested 3 more scripts and also tested all scripts with a much larger image of 1600 X 1200. As before, no significant differences between stacks and standalones in MC and - also as before - a slight improvement for the Rev standalones compared to the Rev stacks, but a remaining difference to the MC equivalents of up to four seconds, and even one script where Rev runs *eleven* times slower than MC! See below. Given this speed loss I'm confident the folks at RunRev will take a keen interest to determine what's eating performance. Offhand I can't imagine how the execution of a single handler with no breaks, pauses, or sends is in any way affected by any outside script, but it does indeed appear to be the case. Have you BZ'd this? It would be good to include that file as an attachment to the report. I might do this after some more research -- Richard Gaskin Fourth World Media Corporation and Chipp Walters (on Wed, 11 Oct 2006) wrote: Wilhelm, Just wondering, did you 'lock messages' before and 'unlock messages' after when running the script? If not, you might want to try it and see if it doesn't speed things up. Inserting lock messages etc. does not change the results. But thanks for the hint, because the fact that adding lock messages does not change the speed means that the long setProp cREVGeneral [pwhichProp] pWhichProfile handler (which belongs to the scripts added by the Rev Standalone Builder) cannot be the culprit. Unfortunately, all these extra scripts apparently are added by the script-protected revsaveasstandalone substack. I searched the scripts of the StandaloneSettings stacks and so far found nothing there that could be related to the speed difference problems. Also, you probably want to make sure 'Variable Checking by Default is turned OFF in the prefs pane for RR. Same as above, does not make any difference. best, Chipp Here are some results for filters applied to the larger 1600 X 1200 image (again: Windows computer with 2 GHz): - duplicate colors: Rev is * three seconds* slower in all the 3 stacks and standalones ( 9 vs. 12 and 10 vs. 13 seconds with different engine versions) - max dots (this is a modified version of the Gimp despeckle-median filter, where I exchanged the median for the max values. The button is to be found in my Imagedata Toolkit below the despeckle filter). Rev is about 4 seconds slower here, the results being 34 seconds for MC and 38.5 for Rev on the average. I then happened to notice that the reset button worked considerably slower in Rev, eleven times slower, and I measured this. The script of the reset button is a one-liner set the imagedata of img 1 to decompress(the Bilddaten of me) -- (Bilddaten being a translation of imagedata). This takes 270 milliseconds in MC and 3000 milliseconds in Rev with all engine versions and identical in stacks and standalones. I removed compress for setting the custom property and decompress then in the reset handler, which didn't make much of a difference: Rev is now only 10 times slower.-- Anyway, after the compress-decompress-reset tests, I made some progress in detecting what is involved in producing the speed-difference problems. Instead of the image I placed a field with a longer text on the card, which then was saved as a custom property of the reset button. Resetting the text of the field is indeed identical in all Rev and MC stacks and standalones, meaning that the speed differences between MC and Rev are caused by a different handling of imagedata! It now remains to be found out which script is responsible for this abject treatment of imagedata in Revolution, where this script is located, and how we can prevent its interference. Best regards, Wilhelm Sanke http://www.sanke.org/MetaMedia ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: Speed differences between MC and Rev (problem area nearly found)
Wilhelm Sanke wrote: In the meantime I did further tests and built standalones for MC 2.6.5, 2.73, 2.74 and Rev 2.6.1, 2.73, 2.74. I tested 3 more scripts and also tested all scripts with a much larger image of 1600 X 1200. As before, no significant differences between stacks and standalones in MC and - also as before - a slight improvement for the Rev standalones compared to the Rev stacks, but a remaining difference to the MC equivalents of up to four seconds, and even one script where Rev runs *eleven* times slower than MC! See below. Very valuable info for RunRev. Thanks for taking the time to verify that test. It now remains to be found out which script is responsible for this abject treatment of imagedata in Revolution, where this script is located, and how we can prevent its interference. I'm wondering if it isn't script execution at all, but perhaps memory. I can't think of any way your script could be affected by the mere existence of other scripts, since your main handler is pretty well self-contained (so send or other such things which might give RR's scripts some chance to intercede). I don't believe that the scripts RR's standalone maker insists on adding to one's project are all that large, but perhaps in an intensive environment such as your image processing script requires the difference may be just enough to affect performance. How much RAM is installed on your machine? I'm grasping at straws here, but this is such an unexpected result that as far as causes go it may be worth remaining open to possibilities which may even seem unlikely. -- Richard Gaskin Fourth World Media Corporation Developer of WebMerge: Publish any database on any Web site ___ [EMAIL PROTECTED] http://www.FourthWorld.com ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: Speed differences between MC and Rev
Wilhelm, Just wondering, did you 'lock messages' before and 'unlock messages' after when running the script? If not, you might want to try it and see if it doesn't speed things up. Also, you probably want to make sure 'Variable Checking by Default is turned OFF in the prefs pane for RR. best, Chipp ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: Speed differences between MC and Rev
Wilhelm Sanke wrote: I resend my post of last Friday, hoping the server is up again: On Sun, 24 Sep 2006 Richard Gaskin wrote: I notice no difference in the execution speed. So far this is consistent with all data except Wilhelm's. Neither logically nor empirically have we yet found a way that simply adding a library can affect execution speed. We'll have to wait for Wilhelm to provide more data. (snip) If instead there does seem to be some difference in the way standalones are made (though after building my own standalone maker I can honestly report that I can't imagine what that could be) it's also worthwhile determining where the performance goes. Ideally Wilhelm will be able to come up with a stack that presents an isolated recipe for this problem. It's my understanding that at the moment the tests are being run within a very complex collection of scripts, making it difficult to produce a generalized recipe for others to run. Without such an isolated example of this reported issue, I can't think of any way it could be reasonably addressed further beyond what's already be done. If he's able to deliver an isolated example I'm sure RunRev will jump at the chance to optimize based on it reveals. -- Richard Gaskin Back again to resume the discussion. I have produced this isolated example. Apart from the one-line script of the reset button, it contains only a 13-line script of the test button duplicate colors. Only the MC cursors stack is included as a substack, otherwise nothing is included, not even an answer dialog. The performance differences are as reported about 600 milliseconds between MC and Rev on a Windows 2 GHz machine, tested with Metacard and Rev using the same 2.7.3 engine. No differences come up for the stacks compared with standalones. A test with 2.7.4 today shows an overall performance improvement for both IDEs of about 200 milliseconds, but the speed difference between MC and Rev of now about 500 milliseconds remains. Stack and standalone with MC show an identical performance - around 1550 and always below 1600 milliseconds. For Rev - 1935 to 2083 milliseconds for the standalone - there is an additional difference between standalone and stack of 100 milliseconds, the stack running in the IDE with a peak of 2165 milliseconds being the slower one. You can download the test stack from here (2 MB because of the embedded picture and the compressed imagedata to enable reset): http:/www.sanke.org/Software/mc-rev_speed_test.rev or type go URL http:/www.sanke.org/Software/mc-rev_speed_test.rev in your message box. Good work, Wilhelm. Confirmed in the IDEs -- 5740ms/avg in MC, 6830ms/avg in Rev (I have a 1GHz PB G4). I haven't built standalones, though, which would be good to test. Given this speed loss I'm confident the folks at RunRev will take a keen interest to determine what's eating performance. Offhand I can't imagine how the execution of a single handler with no breaks, pauses, or sends is in any way affected by any outside script, but it does indeed appear to be the case. Have you BZ'd this? It would be good to include that file as an attachment to the report. -- Richard Gaskin Fourth World Media Corporation ___ [EMAIL PROTECTED] http://www.FourthWorld.com ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: Speed differences between MC and Rev
I resend my post of last Friday, hoping the server is up again: On Sun, 24 Sep 2006 Richard Gaskin wrote: I notice no difference in the execution speed. So far this is consistent with all data except Wilhelm's. Neither logically nor empirically have we yet found a way that simply adding a library can affect execution speed. We'll have to wait for Wilhelm to provide more data. (snip) If instead there does seem to be some difference in the way standalones are made (though after building my own standalone maker I can honestly report that I can't imagine what that could be) it's also worthwhile determining where the performance goes. Ideally Wilhelm will be able to come up with a stack that presents an isolated recipe for this problem. It's my understanding that at the moment the tests are being run within a very complex collection of scripts, making it difficult to produce a generalized recipe for others to run. Without such an isolated example of this reported issue, I can't think of any way it could be reasonably addressed further beyond what's already be done. If he's able to deliver an isolated example I'm sure RunRev will jump at the chance to optimize based on it reveals. -- Richard Gaskin Back again to resume the discussion. I have produced this isolated example. Apart from the one-line script of the reset button, it contains only a 13-line script of the test button duplicate colors. Only the MC cursors stack is included as a substack, otherwise nothing is included, not even an answer dialog. The performance differences are as reported about 600 milliseconds between MC and Rev on a Windows 2 GHz machine, tested with Metacard and Rev using the same 2.7.3 engine. No differences come up for the stacks compared with standalones. A test with 2.7.4 today shows an overall performance improvement for both IDEs of about 200 milliseconds, but the speed difference between MC and Rev of now about 500 milliseconds remains. Stack and standalone with MC show an identical performance - around 1550 and always below 1600 milliseconds. For Rev - 1935 to 2083 milliseconds for the standalone - there is an additional difference between standalone and stack of 100 milliseconds, the stack running in the IDE with a peak of 2165 milliseconds being the slower one. You can download the test stack from here (2 MB because of the embedded picture and the compressed imagedata to enable reset): http:/www.sanke.org/Software/mc-rev_speed_test.rev or type go URL http:/www.sanke.org/Software/mc-rev_speed_test.rev in your message box. Best regards, Wilhelm Sanke ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: Speed differences between MC and Rev
Rob wrote: Result: The Rev version has about 45k more of scripts in it including 3 references to stack Home (MC version has none). It would appear that Rev is including scripts that are not actually needed, how much this would effect speed is debateable though especially when run on modern hardware. Having conducted some rudimentry comparisons on my machine (AMD 4200+ x2, 1gb DDR400, Win XP 32bit) using a variety of stacks (including ImageData Toolkit) I notice no difference in the execution speed. So far this is consistent with all data except Wilhelm's. Neither logically nor empirically have we yet found a way that simply adding a library can affect execution speed. We'll have to wait for Wilhelm to provide more data. Unless there's something wrong with his benchmarking method, the result will be worth investigating: If his benchmarks are simply the result of an engine version mismatch, then if the Rev engine is later it would be worthwhile determining where the performance went between engine builds. If instead there does seem to be some difference in the way standalones are made (though after building my own standalone maker I can honestly report that I can't imagine what that could be) it's also worthwhile determining where the performance goes. Ideally Wilhelm will be able to come up with a stack that presents an isolated recipe for this problem. It's my understanding that at the moment the tests are being run within a very complex collection of scripts, making it difficult to produce a generalized recipe for others to run. Without such an isolated example of this reported issue, I can't think of any way it could be reasonably addressed further beyond what's already be done. If he's able to deliver an isolated example I'm sure RunRev will jump at the chance to optimize based on it reveals. -- Richard Gaskin Fourth World Media Corporation ___ [EMAIL PROTECTED] http://www.FourthWorld.com ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: Speed differences between MC and Rev
Hi all, I have suddenly felt the urge to un-lurk myself :). As the licensing of Revolution is now in the engine allowing full use of MC with the Studio version of Rev I am ready to purchase and I am interested in this speed difference issue. So I decided to have a bit of a look. First I created an empty stack (no controls or anything) in Rev then I made 2 standalones, one with the Rev builder and one with MC, these I then compared with a hex editor. Result: The Rev version has about 45k more of scripts in it including 3 references to stack Home (MC version has none). It would appear that Rev is including scripts that are not actually needed, how much this would effect speed is debateable though especially when run on modern hardware. Having conducted some rudimentry comparisons on my machine (AMD 4200+ x2, 1gb DDR400, Win XP 32bit) using a variety of stacks (including ImageData Toolkit) I notice no difference in the execution speed. the size difference between the Rev and MC versions of the ImageData Toolkit that I made is considerably larger than between the two empty test standalones (128k as opposed to 45k), speed does not appear to be affected. Rob Tucker [EMAIL PROTECTED] ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: Speed differences between MC and Rev
Rob wrote: Hi all, I have suddenly felt the urge to un-lurk myself :). As the licensing of Revolution is now in the engine allowing full use of MC with the Studio version of Rev I am ready to purchase and I am interested in this speed difference issue. So I decided to have a bit of a look. First I created an empty stack (no controls or anything) in Rev then I made 2 standalones, one with the Rev builder and one with MC, these I then compared with a hex editor. Result: The Rev version has about 45k more of scripts in it including 3 references to stack Home (MC version has none). It would appear that Rev is including scripts that are not actually needed, They are needed for any stack that uses the rev-based commands that are listed in the Rev dictionary. There are so many users who do call those handlers that I think it makes sense to embed that library as a standard extension. Tech support would collapse under the volume of complaints if it weren't in there; users would assume that Rev's standalones were broken. Now that I think about it, quietly embedding a library that doesn't get in the way of anything is a pretty good decision for supporting ease of use, especially for novice users who may not understand what libraries do or why they need them. how much this would effect speed is debateable though especially when run on modern hardware. Having conducted some rudimentry comparisons on my machine (AMD 4200+ x2, 1gb DDR400, Win XP 32bit) using a variety of stacks (including ImageData Toolkit) I notice no difference in the execution speed. the size difference between the Rev and MC versions of the ImageData Toolkit that I made is considerably larger than between the two empty test standalones (128k as opposed to 45k), speed does not appear to be affected. I use both IDEs routinely, and I've never noticed any speed difference either. Something else must be going on with certain stacks. The differences in sizes may be due to changes in the standalone settings; did you use the same settings for both sets of test stacks and their apps? It may be that more options were included in one set than in the other. The extra 45k of scripts you noticed were most likely the revCommon library (which I mistakenly refered to as revGeneral before.) But Kevin confirms it uses almost no system message handlers, so it couldn't interfere unless a stack needs to intercept a lot of mouseDoubleUps. -- Jacqueline Landman Gay | [EMAIL PROTECTED] HyperActive Software | http://www.hyperactivesw.com ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: Speed differences between MC and Rev
On 9/24/06 12:16 AM, J. Landman Gay [EMAIL PROTECTED] wrote: Rob wrote: They are needed for any stack that uses the rev-based commands that are listed in the Rev dictionary. There are so many users who do call those handlers that I think it makes sense to embed that library as a standard extension. Tech support would collapse under the volume of complaints if it weren't in there; users would assume that Rev's standalones were broken. Now that I think about it, quietly embedding a library that doesn't get in the way of anything is a pretty good decision for supporting ease of use, especially for novice users who may not understand what libraries do or why they need them. Well, I'd agree with you if the Standalone Builder didn't have the default radio button action under Inclusions state Search for required inclusions when saving the standalone application. This gives the impression that a search is being made... which is of course accurate, since when I built my first version to test this, it output two backscripts (revCommon and revLibURL) because I'd used url in my button. When I removed the url from my button, it didn't include revLibURL. Personally it doesn't bother me that revCommon is included; I think that it should be mentioned in the Standalone Builder somewhere (like a footnote or something). If not, then the other approach would be for the Standalone Builder to actually search for inclusions of revCommon handlers and functions. Either way works for me... Ken Ray Sons of Thunder Software Web site: http://www.sonsothunder.com/ Email: [EMAIL PROTECTED] ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: Speed differences between MC and Rev and the origin of the English language
On Fri, 22 Sep 2006, Dave Cragg [EMAIL PROTECTED], wrote: The people of Edinburgh and the area to the south east did fight with the Angles of Northumbria. But these were neither Picts nor Scots. They were Britons who spoke what today would be recognised as Welsh. Interestingly, these battles are more remembered in Welsh history than in Scottish history. (Also, some people think Arthur was the leader of a tribe of Scottish Britons, and that he fought against both Angles and Picts.) Eventually, the Angles dominated south east Scotland and the Scots and Picts dominated the remainder of the country. The use of Welsh in Scotland died out. The database I based my judgment on was small, and I had warned you that only about 99% of my story was true. There were so many different kingdoms or territories governed by warlords at that time that one can easily become confused. But I think the general picture is true. It is rumoured that there are many missing libraries of that period, thought to be hidden in southern Scotland somewhere. It may be that one of these libraries has got buried in the Rev IDE. (Some of those scripts look like Welsh to me.) I also read somehwere that the Romans introduced the bagpipes to Scotland, but left before they taught people how to tune them. Cheers Dave It could well be that the Romans instroduced the instrument to Scotland, but did not particularly like the sounds coming out of it. A quote from Wikipedia: Nero is reported to have said he would play them (bagpipe is plural in Latin) in public as a penance for not winning a poetry contest.- In case my comments were felt to be offensive, I apologize to the Scottish branch of my family, who are however living more near Glasgow. Cheers, Wilhelm ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: Speed differences between MC and Rev and the origin of the English language
Wilhelm Sanke wrote: Apart from the parts of my own scripts that are unprotected I see a lot of extra code, some of which may belong to CRevGeneral ... Maybe the last example could be one of the culprits that slow down execution (?) and such as on mouseDoubleUp pButtonNo, pTarget --not been handled --pTarget set in suppress messages frontscript if pTarget is empty then put the long id of the target into pTarget put revTargetStack(pTarget) into tStack put the defaultStack into tDefaultStack set the defaultStack to tStack if the mode of stack tStack is not 0 then click at the clickLoc set the defaultStack to tDefaultStack end mouseDoubleUp Good sluething, Wilhelm. It might be helpful to de-standalone it to take a look at exactly what's been included. Once upon a time someone posted the info needed to strip the executable from the stack -- anyone make a utility for that? A simpler diagnostic might be to have your app spit out a list of frontScripts, backScripts, and libraries, something like this: on LogScripts put the frontScripts cr the stacksInUse cr the backScripts \ in url (file:ScriptList.txt) end LogScripts It might also be helpful to log messages within your standalone using the messageHandled message. This is undocumented, but to have that message sent you first turn on the messageMessages global property, then get your list of handlers: on StartLoggingMessages set the messageMessages to true end StartLoggingMessages In a library somewhere you can include this: on messageHandled global gMessageLog put the params the long name of the target cr after gMessageLog pass messageHandled end messageHandled And to dump it just use: on CloseMessageLog global gMessageLog put gMessageLog into url (file:MessageLog.txt) end CloseMessageLog These scripts are off the top of my head, so please forgive an errors. -- Richard Gaskin Fourth World Media Corporation ___ [EMAIL PROTECTED] http://www.FourthWorld.com ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: Speed differences between MC and Rev and the origin of the English language
On 22 Sep 2006, at 16:10, Wilhelm Sanke wrote: In case my comments were felt to be offensive, Not in any way. It was only because your comments were so interesting that I felt inspired to reply. It's not often we get a thread on something so close to home. Coincidentally, there was a TV show about Nero on the BBC last night. (No bagpipes or Rev libraries were featured.) Cheers Dave ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: Speed differences between MC and Rev and the origin of the English language
Wilhelm Sanke wrote: why should anybody refer to stack home in a standalone? In a standalone, the mainstack becomes home and the term home becomes synonymous with the name of the mainstack, so you can use either. This doesn't answer the rest of your question, of course. -- Jacqueline Landman Gay | [EMAIL PROTECTED] HyperActive Software | http://www.hyperactivesw.com ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: Speed differences between MC and Rev and the origin of the English language
On Fri, 22 Sep 2006, Richard Gaskin wrote: It might be helpful to de-standalone it to take a look at exactly what's been included. Once upon a time someone posted the info needed to strip the executable from the stack -- anyone make a utility for that? In my own collected archives I found this script: on mouseUp answer file Standalone if it is cancel then exit to top put url (binfile:it) into tStack repeat forever -- there's more than one stackfile in there which isinteresting put offset(#!/bin/sh,char 10 to -1 of tStack) into tOff if tOff = 0 then exit repeat put char tOff+9 to -1 of tStack into tStack end repeat ask file Stack if it is cancel then exit to top set the fileType to RevoRSTK put tStack into url (binfile:it) answer conversion finished with OK end mouseUp This, however, (on Windows) provides me with an extracted stack that is flagged as corrupted, even if I comment out the line about the filetype which is probably meant only for MacOS(?) A simpler diagnostic might be to have your app spit out a list of frontScripts, backScripts, and libraries, something like this: on LogScripts put the frontScripts cr the stacksInUse cr the backScripts \ in url (file:ScriptList.txt) end LogScripts Applying this I get 13 front and back scripts running in the stack and nothing of this in the standalone (in the standalone only my script library clib and the calling button for listing the back and frontscripts are listed). When I remove these backscripts and frontscripts in the stack no change of the slower Rev-IDE speed is effected. So the slower performance in Rev must be caused by other scripts.- Unfortunately I cannot follow your other suggestions at the moment (startloggingMessages etc.) because I really need to concentrate on other things at the moment (and not only, but also, because of that voluminous doctoral dissertation on my desk). I will continue the discussion in about a week and thank all of you in the meantime for your interest in this thread. Best regards, Wilhelm Sanke ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: Speed differences between MC and Rev and the origin of the English language
Wilhelm Sanke wrote: When I remove these backscripts and frontscripts in the stack no change of the slower Rev-IDE speed is effected. So the slower performance in Rev must be caused by other scripts.- Very odd. If the problem is indeed related to Rev's standalones, then I would imagine there should be a measurable difference with just about any of us who switch between IDEs. Have any of the rest of you seen performance differences between your standalones built with MC and those built with Rev? -- Richard Gaskin Fourth World Media Corporation ___ [EMAIL PROTECTED] http://www.FourthWorld.com ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: Speed differences between MC and Rev and the origin of the English language
On 9/22/06 4:13 PM, Wilhelm Sanke [EMAIL PROTECTED] wrote: Applying this I get 13 front and back scripts running in the stack and nothing of this in the standalone (in the standalone only my script library clib and the calling button for listing the back and frontscripts are listed). Well, I created a simple standalone with Rev 2.7.4 with just a button that spat the scripts out, and left the Search for required inclusions radio button on, and it inserted no frontscripts, no libraries, and 2 backscripts: revLibURL and revCommon. Just contributing to the discussion... :-) Ken Ray Sons of Thunder Software Web site: http://www.sonsothunder.com/ Email: [EMAIL PROTECTED] ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: Speed differences between MC and Rev and the origin of the English language
On 21/9/06 22:37, Richard Gaskin [EMAIL PROTECTED] wrote: I believe the revGeneral library is always included. There is no option to turn it off, which is usually okay, since the majority of Rev users need at least some part of that library. What a strange design decision. I've helped more than a few people diagnose errors in standalones that weren't evident in the IDE because of the additional objects being added to their first card. Such errors are particularly hard to pin down because the objects don't exist in the IDE, which is the only environment that can run a debugger. I can see having an Include revGeneral option turned on by default, but preventing people from doing anything else seems really odd. One more reason to improve MC IDE for the masses: it's the only way to make truly native Rev apps. :) To suggest that a standalone is not a truly native Revolution application because it contains Revolution code libraries seems nonsensical. Does that mean that a standalone containing libURL is not a truly native Revolution application? There is no such library as revGeneral. You may be thinking of the revCommon library. If this is the library you mean, it seems unlikely that this library would be responsible for a drop in performance given that the only system message it intercepts is mouseDoubleUp - sending a mouseUp to objects, in the same way the MetaCard IDE has done since the dawn of time. All the other message handlers in there are there to support those terms we define as part of the language definition and include in the dictionary. Basics such as revCopyFolder. Its quite a compact library. The bigger libraries are all optional. Whatever is causing the performance difference is unlikely to be that library. But if it is, well its like any other part of the product and could contain bugs along with the engine, the IDE, the OS, a database driver, etc. Errors introduced by including objects on the first card of a standalone are a pain, I fully agree. That original design decision historically stems from the need to deliver extensive functionality libraries (today in constant use in the vast majority of standalone applications out there), and not having control over the engine and therefore capability to create an official place to put them. Doing this better will come about as we improve the overall product architecture and create a place for this sort of thing. It won't come about by us hacking in a quick fix that will doubtless introduce its own quirkiness. Relative to the time you have already waited for this, it won't be much longer. In the mean time, rather than spending time being surprised that we would attempt to deliver feature libraries with useful functionality for our user base to include in standalones, we would as ever welcome constructive suggestions on how to continue progress on making what we have work better and more reliably. Kind regards, Kevin Kevin Miller ~ [EMAIL PROTECTED] ~ http://www.runrev.com/ Runtime Revolution - User-Centric Development Tools ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Speed differences between MC and Rev and the origin of the English language
Home again and back to work as I announced 11 days ago. There is a 350-pages doctoral dissertation on my desk - a study about internet use in schools - which I need to assess and grade during the next two weeks, but I resume paying some attention to my imagedata stuff and MC. My two vacations this summer were spent in parts of Germany where language minorities still fight against assimilation. Last week I visited the Sorbian area near Poland where a small number of people still speak their old Slavonic language which is also still used in schools. In July I spent a quiet time in the northernmost county of Germany, called land Angeln since 2000 years - South of the Danish border - from where the English language and especially the name for the English language originated. I had taken my laptop with me to the land Angeln to work on my imagedate toolkit, but in the first night the harddisk crashed and I had two weeks time to attend to other matters and study the local culture and what had remained from old times; additionaly I consulted my memory and later Wikipedia and my old textbooks. As you all on this list are more or less familiar with the English language it will not hurt to share my collected insights about its origin: The short story of the development - and about 99% of this is true - runs like this (and the Scots are also instrumental here, if only in a somewhat negative way): The Roman emperor Hadrian had built his Hadrian's wall across England from Newcastle to Carlisle because he did not like bagpipe music and kilts. When the Roman empire broke down in the 4th century, the revolutionaries from Edinburgh again annoyed the Celtic population South of the Hadrian's wall. Then the British Celts asked two former Roman mercenaries, namely Hengist and Horsa, to help them against the Scots. Hengist and Horsa happened to belong to the Anglian tribe in the land Angeln and asked their relatives and more tribesmen over to Britain. The Saxons - South of the land Angeln - and the Jutes to the North joined them and established their kingdoms (and languages) in the new country. The last Celtic king to fight against this invasion was the legendary King Arthur from Tintagel in Cornwall. Later other waves of immigrants came over to England from the same places where the Anglians, the Saxons, and the Jutes originally lived. From the eight century on the Vikings made frequents inroads and then settled in England (the famous Hägar was one of them). In about 10 miles distance from where I spent my July vacation is Haithabu, the former trade center of the Vikings in the land Angeln (a place similar to Sutton Hoo in England, where big Viking ships have also been found). In the 11th century after Hastings the Normans, which were originally Vikings, too, came over who had made a detour through the Normandy in France, got civilized there and had learned some French and French cuisine in the meantime. Then even later more Northern Germanic tribes invaded, especially Jutes (Danes) who established the Danelag in England. Knud the Great was at the same time King of England and Angeln/Denmark/Norway. All these Germanic tribes spoke closely related Germanic dialects very similar to the language documented in Beowulf, the oldest extant example of poetic Old-English language. Interestingly, the venue of the saga told in Beowulf, this center piece of Old-English literature, is the Southern area of Scandinavia. By the time of Chaucer the Anglian/English language had evolved as the widely spoken and officially used means of communication in the new England. It is an astonishing fact of language development that the term Anglian/English , derived from the small land-Angeln region of continental Europe, finally prevailed as the name for one the most important languages and the lingua franca for international communication of today. At least the Saxon part of this language development is honored when we sometimes also speak of Anglo-Saxons and Anglo-Saxon languages.-- == Now to the speed differences: On Sat, 09 Sep 2006, Richard Gaskin [EMAIL PROTECTED] had written (Subject: Re: [ANN]: Imagedata Toolkit (beta) released): Wilhelm Sanke wrote: (Remark for Metacard list members only: For optimal performance use the Metacard IDE. When run in the Revolution IDE some filters need up to 45% more processing time than in MC. This also holds when you create a standalone.) How could that be possible when they both use the same engine? The Rev IDE is a slowly evolving environment with about 20 times more code than in the MC IDE. Given the additional intricacy and interrelatedness of this code it is quite natural that speed and other problems occur. Some of my earlier stacks - the discussion about this and examples are still to be found on my website (I will remove them soon) - would not even start in the Rev IDE or crash or could not be
Re: Speed differences between MC and Rev and the origin of the English language
Wilhelm Sanke wrote: On Sat, 09 Sep 2006, Richard Gaskin [EMAIL PROTECTED] had written (Subject: Re: [ANN]: Imagedata Toolkit (beta) released): Wilhelm Sanke wrote: (Remark for Metacard list members only: For optimal performance use the Metacard IDE. When run in the Revolution IDE some filters need up to 45% more processing time than in MC. This also holds when you create a standalone.) How could that be possible when they both use the same engine? The Rev IDE is a slowly evolving environment with about 20 times more code than in the MC IDE. Given the additional intricacy and interrelatedness of this code it is quite natural that speed and other problems occur. Some of my earlier stacks - the discussion about this and examples are still to be found on my website (I will remove them soon) - would not even start in the Rev IDE or crash or could not be inspected by the application browser or property inspectors because these tools were unable to handle larger number of objects in a stack. The Rev IDE indeed has considerably improved over time, but IMHO has still a while to go to become a reliable and more user-friendly application. As to standalones, apparently something is being added to them in Rev what is happily missing in Metacard. So it would seem. Logically speaking, the same engine with the same scripts should produce equivalent performance. I don't dispute the results, so there must be some difference here. If you're certain the engine version is the same when building standalones in both MC and Rev, then we can rule that out. That leaves us with the possibility that Rev is including some of its scripts even when you tell it not to. When you pour through the standalone with a raw editor do you see any Rev scripts in there? -- Richard Gaskin Managing Editor, revJournal ___ Rev tips, tutorials and more: http://www.revJournal.com ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: Speed differences between MC and Rev and the origin of the English language
Richard Gaskin wrote: That leaves us with the possibility that Rev is including some of its scripts even when you tell it not to. I believe the revGeneral library is always included. There is no option to turn it off, which is usually okay, since the majority of Rev users need at least some part of that library. -- Jacqueline Landman Gay | [EMAIL PROTECTED] HyperActive Software | http://www.hyperactivesw.com ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: Speed differences between MC and Rev and the origin of the English language
J. Landman Gay wrote: Richard Gaskin wrote: That leaves us with the possibility that Rev is including some of its scripts even when you tell it not to. I believe the revGeneral library is always included. There is no option to turn it off, which is usually okay, since the majority of Rev users need at least some part of that library. What a strange design decision. I've helped more than a few people diagnose errors in standalones that weren't evident in the IDE because of the additional objects being added to their first card. Such errors are particularly hard to pin down because the objects don't exist in the IDE, which is the only environment that can run a debugger. I can see having an Include revGeneral option turned on by default, but preventing people from doing anything else seems really odd. One more reason to improve MC IDE for the masses: it's the only way to make truly native Rev apps. :) -- Richard Gaskin Managing Editor, revJournal ___ Rev tips, tutorials and more: http://www.revJournal.com ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: Speed differences between MC and Rev and the origin of the English language
On 21 Sep 2006, at 20:40, Wilhelm Sanke wrote: The Roman emperor Hadrian had built his Hadrian's wall across England from Newcastle to Carlisle because he did not like bagpipe music and kilts. When the Roman empire broke down in the 4th century, the revolutionaries from Edinburgh again annoyed the Celtic population South of the Hadrian's wall. Then the British Celts asked two former Roman mercenaries, namely Hengist and Horsa, to help them against the Scots. Hengist and Horsa happened to belong to the Anglian tribe in the land Angeln and asked their relatives and more tribesmen over to Britain. The Saxons - South of the land Angeln - and the Jutes to the North joined them and established their kingdoms (and languages) in the new country. The last Celtic king to fight against this invasion was the legendary King Arthur from Tintagel in Cornwall. At the risk of going way off topic... Wilhelm, I agree that the origins of the speed issue probably lie in Edinburgh, and I'd be happy to see you and your Angeln friends sort this out. But the people whose troublesome invasions Hengist and Hrosa were invited to resist were Picts and not Scots. The Scots had not yet arrived in Britain in great numbers at that time. The people of Edinburgh and the area to the south east did fight with the Angles of Northumbria. But these were neither Picts nor Scots. They were Britons who spoke what today would be recognised as Welsh. Interestingly, these battles are more remembered in Welsh history than in Scottish history. (Also, some people think Arthur was the leader of a tribe of Scottish Britons, and that he fought against both Angles and Picts.) Eventually, the Angles dominated south east Scotland and the Scots and Picts dominated the remainder of the country. The use of Welsh in Scotland died out. It is rumoured that there are many missing libraries of that period, thought to be hidden in southern Scotland somewhere. It may be that one of these libraries has got buried in the Rev IDE. (Some of those scripts look like Welsh to me.) I also read somehwere that the Romans introduced the bagpipes to Scotland, but left before they taught people how to tune them. Cheers Dave ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: Speed differences between MC and Rev and the origin of the English language
Richard Gaskin wrote: What could revGeneral possibly be doing that affects the execution of scripts that don't call any of its handlers? Probably nothing; I only mentioned it because you were wondering if any libraries were included in app builds. But if a script doesn't call any handlers in the library, then of course it wouldn't interfere. What I'm fuzzy on, and don't have time to look up, is whether there are any handlers in there that might be called automatically; for example, if it catches any system messages and then passes them on. It might, but I haven't checked. We just might have stumbled onto Rev's tech support holy grail: if revGeneral turns out to be such an unruly citizen, invoking its own handlers independent of the developer's control, the implications for other bugs reported by developers and their end-users are potentially quite broad. Probably not wise to make assumptions before we find out. It might be something entirely different. But if it turns out that revGeneral operates in a polite, clean way that doesn't unexpectedly alter normal script execution, then what could be causing Wilhelm's performance drop? Still a mystery; I don't know. -- Jacqueline Landman Gay | [EMAIL PROTECTED] HyperActive Software | http://www.hyperactivesw.com ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: Speed differences between MC and Rev and the origin of the English language
Dave Cragg wrote: I also read somehwere that the Romans introduced the bagpipes to Scotland, but left before they taught people how to tune them. snork! I have always wondered about those bagpipes. Thanks for clearing this up. :) -- Jacqueline Landman Gay | [EMAIL PROTECTED] HyperActive Software | http://www.hyperactivesw.com ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
