Hi Bill,

> These guidelines are great, but I was hoping for some kind of 
> benchmarks, so I could get a sense of the potential for J2EE 
> compilation.  From a standpoint of complete ignorance, it seems to me 
> that a J2EE app might optimize differently.

Sorry I don't have benchmark data for you, but you can rest assured a compiled 
application (e.g., J2EE) will execute faster than a interpreted language 
application (witango). 


> Viz., meta tags vs. actions.  An action conceivably maps more or less 
> directly to byte-code, which is then further compiled at run-time. 
> OTOH, metatags in an action are more likely to be interpreted within 
> the witango Java library.  If so, then it would justify my bias 
> toward action-oriented visual programming (which I like from the 
> maintenance standpoint), since I could then guesstimate the speed/ 
> dollar trade-off.

This is hard to answer because none of us are privy to how Phil has actually 
built his J2EE compiler. But I can offer you this tidbit of an observation, 
with regards to Metatags vs. Actions for J2EE applications. 

From the perspective of the J2EE conversion, metatags and actions are just 
instructions and references, so I bet there is no or little difference when it 
comes to compiling your witango code as Java. You'll get the same execution 
logic and speed from J2EE regardless if you wrote the original code with 
metatags or actions. 

Remember witango is just an interpreted language, where witango gives you two 
ways to write those instructions and references (via either metatags or 
actions). 

To understand the above statements you need to separate the fact that variables 
in witango are represented by metatags (references). 

Take the variable metatags out of the metatag collection and you are generally 
left with functional metatags (instructions) - many of which are also 
replicated as Actions (instructions, again). You have to take them out of the 
collection because Actions still use the same metatag variable references 
(short-hand or long-hand, no difference). Their values are not compiled to 
byte-code, but rather just the pointer references. 

So if I've understood your question correctly, and your target platform is 
J2EE, write your witango code according to the pre-compile guidelines and then 
use either metatags or actions (depending on your taste) and I believe you'll 
get the same results whether you wrote with functional metatags or actions. 


~~~ 
But....if your target platform is "not" J2EE, and speed "is" the top concern, 
then I would follow the recommendations as pointed out earlier (including 
Anthony's additional comments). 

So why are some things slower in the witango runtime than other things? Because 
again witango is an interpreted language, meaning every statement has to be 
parsed and analyzed prior to "every" execution, and the more complex the 
instructions, the longer it takes to interpret them. 

~ TML files are plain text (as big as you write them), TAF files are large XML 
documents (many times larger than what you see in your editor). 

~ Metatags are brief statements you type, Action definitions are stored 
internally in a TAF or TCF as complex XML data. 

And because witango is an interpreted language, the type of process involved 
during the runtime interpretation and pass-off of the finished results to the 
execution engine also requires much more memory consumption than a compiled 
J2EE app (where all the heavy lifting has taken place before-hand, and out of 
process). 

I hope that helps.

Scott,


> Bill
> 
> 
> On Mar 16, 2008, at 10:51 AM, Anthony M. Humphreys wrote:
> 
>> Scott,
>>
>> Well said. And quite correct. 
>>
>> Although I would have added a few:
>> 
>>  ~ Every action, even a group action, creates an object instance 
>> internally within the server, which is overhead that slows the 
>> execution.
>> 
>>  ~ Branching within a TAF is faster than branching outside the TAF; 
>> both are faster than TCF Methods.
>> 
>>  ~ Many small TAF files are faster than one monolithic one with 
>> many if actions.
>> 
>>  ~ The speed differences mean less on a fast server than on a slow 
>> server.
>> 
>>  ~ Code optimized this way is a dog to maintain!
>> 
>>  ~ Often times, it is faster to get the Database to some of the 
>> work for you than to do it in code, like calculations.
>> 
>>  ~ Lastly, there is often more speed to be gained from optimising 
>> the Database than from optimising the code; use a fast Database 
>> server on different machine than the Witango server, for instance, 
>> and optimise the indexes.
>> 
>> As with all writing, is better to achieve clarity than concision. 
>> 
>> Since the bulk of the lifetime of any code is not in the initial 
>> writing, but in maintenance, you are better off writing code that 
>> is descriptive and clear in its purpose than to write "fast" code 
>> in almost all cases. Only in the most rare of cases does one truly 
>> need to optimize code for speed.
>> 
>> Compiling to J2EE provides an opportunity to internally optimise 
>> code and codes structures; I don't know what With has done on this 
>> front, so you may need to roll up your sleeves and create a few 
>> test cases.
>>
>> Anthony -
>> 
>>
>>
>> ----- Original Message ----- 
>> From: "Scott Cadillac" <[EMAIL PROTECTED]> 
>> To: <[email protected]> 
>> Sent: Saturday, March 15, 2008 19:13 
>> Subject: RE: Witango-Talk: relative speed
>>
>> 
>> Hi Bill,
>> 
>> If speed is all a person is concerned about, with regards to 
>> witango code, then:
>> 
>> ~ Caching is faster than not caching.
>> 
>> ~ NOT compiling to "Runtime only" is faster than compiled. 
>>
>> ~ Metatags are faster than Actions.
>> 
>> ~ TML files are faster than TAF files.
>> 
>> ~ A TAF or TML with Includes is slower than a file without any 
>> Includes.
>> 
>> ~ Branches are faster than TCF Methods.
>> 
>> ~ Lots of user scope variables are more expensive than lots of 
>> local scope variables.
>> 
>> These things are contrary to managing your code in an optimum way 
>> of course, but the reasoning can be summed up this way: 
>> 
>> Most anything that makes a programmer's job easier, makes the code 
>> run slower.
>> 
>> Compiling to J2EE is an entirely different question, because it's 
>> no longer witango. Others can give you more advice with regards to 
>> J2EE than me, but I suspect J2EE is generally faster than witango. 
>>
>> Hope that helps.
>>
>> Scott, 
>>
>>
>> 
>> On Saturday, March 15, 2008 7:33pm, William M Conlon 
>> <[EMAIL PROTECTED]> said:
>> 
>>> Has anyone run tests comparing the relative speed of a procedure when 
>>> implemented in actions as opposed to metatags in HTML Results? 
>>> 
>>> I would be curious to see a comparison of these two approaches for: 
>>> Non-cached
>>> cached
>>> compiled. 
>>> 
>>> To me, the action approach is more amenable to server-side speed-up, 
>>> especially when compiled for J2EE, but I would be curious to see the 
>>> difference. My bias has been to use actions for most things related 
>>> to business logic, because I think it is easier to have the logic 
>>> exposed when I crack open an old or unfamiliar file. 
>>> 
>>> But there are some corner cases, where I could go either way. And 
>>> there are some frequently-called methods that I would like to 
>>> optimize for speed.
>>>
>>> 
>>> Bill
>>> 
>>> _____________________________________________________________________ 
>>> ___ 
>>> TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf 
>>>
>>>
>> 
>> ______________________________________________________________________ 
>> __ 
>> TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf 
>> 
>> ______________________________________________________________________ 
>> __ 
>> TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf 
>> 
> ________________________________________________________________________ 
> TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf 
> 
> 

________________________________________________________________________
TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf

Reply via email to