World: r3wp

>> s: now/precise a: func [][return none] loop 1000000 [a]  difference 
now s
== 0:00:01.032

>> s: now/precise a: func [][none] loop 1000000 [a]  difference now 
s
== -0:00:00.296

in this case the difference is 70%

now if I have a 1000 line function that either teminates in a return 
or just the value .. how much does it affect it?

the larger the func, the less hit, you can see that each function 
call is taking more time to initialise because of the return.

its just a question of maximising performance, and I know dockimbel 
is very serious about improving cheyenne's .

so, in reality it may matter very little

he is using return everywhere, without possibly realising that it 
might be affecting the whole by 5% overall.

in all processing loops I've measure a resonably high latency, to 
actualy ban it from all of my code.

so how do you break out of a loop ?

I rarely need to do so... I implement the loop conditions properly, 
usually.


obviously there are cases where you really can't live without out 
it... but as a general rule, I rarelly ever need break.

isn't there a way to set the verbose level in the httpd.cfg file?


  I want no arguments to running cheyenne, only config... using args 
  for persistent app is the first point of failure in panic maintenance.

my god cheyenne needs docs.

don't read the above as multiple instances of Doc (although that 
might be the real answer  ;-)

help! cheyenne has no trace.log file in logs, and I can't get the 
verbosity to work without using command-line args which isn't an 
option in my current setup.

what do you mean no trace.log ?

How many instances of Cheyenne are you running?

The log will go to the first instance of Cheyenne started.

the trace.log appears in the chyenne directory if there is an error.

It doesn't appear in the logs/ directory

You can set verbosity in the config file - check the comments in 
the file for how.

no comments of verbosity in my config file.... no trace.log in my 
main cheyenne dir  ' : -/

I've tried to write that line SEVEN times before altme finally didn't 
eat it up or drop connection.

>: - (

It's really bad at present...

Never seen it like this before .....

I only get a trace.log when I get a RSP error.

What is your situation Max?

my cheyenne was crashing (no replies client close connection)  with 
no log, no verbosity.

but I finaly conceded victory to cheyenne and managed to setup args 
for my startup...

and exactly why can't you run it in verbose mode?

but I find it strange that cheyenne doesn't have a trace log for 
all of its accesses/errors.

there is an access.log

I have no .log file of any kind being created in any of the cheyenne 
dirs.

(or uniserve for hat matter)

including the log directory?

this is the latest release. from the web site.

yep... nothing in log

even after you access a web page??

I think that is the thing... it logs only after a succes...

but it should log errors too.  ;-(

I was studying the req object and it has a log? parameter in the 
out  subobject.

so this is a heavily modified cheyenne or straight from doc's site?

download and double click.... but  I'm working on mod-remark, so 
its not currently serving web pages...

still at first, i did see the standard cheyenne pages and don't have 
any logs.

yes! mod-remark has served its very first ever web page  :-)

Re: JS warning in Firebug : that's intentional, it's not a bug, but 
it is bad practice. I'm putting that in my todo list.

RETURN usage: your benchmark doesn't reflect real usage. RETURN cost 
is only significant if you didn't spent much time since you've entered 
in the function. In other terms, if RETURN is at the very beginning 
of the function, it might have a significant (means measurable, doesn't 
imply high) impact on performances, if much code has been processed 
before reaching it, I guess that you won't be able to measure any 
difference in performances.


In Cheyenne's mods, I often use a testing expression at the beginning 
and jumping out if it doesn't match. Let's try to calculate how much 
gain I would get by removing this early RETURN :
    - 500 incoming req/s (extreme load conditions)
    - 10 mods
    - 12 callback / mod (each one having a early RETURN)

    - execution time for testing expression before each RETURN : 0 (will 
    give us the maximum possible final gain)

RETURN evaluation time :  (according to your benchmark)
>> (1.032 - 0.296) / 1E6
== 7.36E-7

# of RETURN evaluated under the testing conditions during 1 sec :
>> 500 * 10 * 12
== 60000

Time spent in 60000 RETURN :
>> 7.36E-7 * 60000
== 4.416E-2			; = 44 ms, roughly 1 / 20 sec


So, under extreme conditions, having a testing condition before RETURN 
taking no time, we can have a maximum gain of 5%.

This translates in real usage in a gain of 0 to 5% depending on server's 
load and test branching conditions performances.


Looking at the testing conditions in current mods, I guess we could 
squizze between 0 and 2% (under extreme load only). I'll try to hunt 
down those early RETURN cases in future versions.


Btw, there's a drawback in not using RETURN, you end up with nesting 
IF/EITHER expressions, which gives you less readable code IMO.

Max: trace.log is only used in verbose mode or in RSP debug mode. 
Access logs are available in %log/ folder (either in Cheyenne's home 
folder or in folder defined with LOG-DIR config keyword).

Also, setting conditions and using IF or EITHER expressions has overhead 
too.

Are the paremters in request/content somehow checked after receving 
from the client if they contain malisous Rebol code or anything else? 
Or is everything just plain converted to string! and that's it?