On Tuesday 25 February 2003 12:52, you wrote:
> I think it would be reasonable to develop some package loading/saving
> feature. I could code one (better one than I have now) in C (speed
> issues), but never had the time. My current ns_pkg is at
> www.nsstuff.zoro.tcl.pl, if anyone's interested.
T
Wojciech Kocjan said:
> From what I noticed, procs stay, variables not, however nothing outside
> global namespace is cleaned up. This is imho good, since packages can
> store data in namespaced variables.
Cool, so seems it's just a cleanup of everything in [info globals]. That's
good to know!
Ba
Bas Scheffers wrote:
Makes sense. So what is cleared up in the interpreter after each request?
Looking at the slides, there is a "command table" and a "variable table".
Looking at Wojciech's post, it seems any procedures created/packages
loaded in the current interpreter stay there, is that correct
Makes sense. So what is cleared up in the interpreter after each request?
Looking at the slides, there is a "command table" and a "variable table".
Looking at Wojciech's post, it seems any procedures created/packages
loaded in the current interpreter stay there, is that correct? And what
about vari
Bas Scheffers wrote:
Cool. Question still remains which is faster, cached .tcl pages or a heavy
master interpreter. Would be interesting to see. May have a play with that
over the next few weeks.
I played a bit with bytecode speed issues on AOLserver as well. Tested
on 3.4.2 with 8.3.4.
First of al
on 2/24/03 3:30 PM, Bas Scheffers at [EMAIL PROTECTED] wrote:
> Don Baccus said:
>>> server with all *.tcl pages cached at least as fast as without, as
>>> long as you have enough RAM. No?
>> Yep.
> Hmmm, is there any docs on the architecture? From the Tcl2K presentation
> slides I assumed it was
Don Baccus said:
>> server with all *.tcl pages cached at least as fast as without, as
>> long as you have enough RAM. No?
> Yep.
Hmmm, is there any docs on the architecture? From the Tcl2K presentation
slides I assumed it was copying the interp for every request, to get a
clean state. Is this not
Andrew Piskorski wrote:
Since AOLserver can be configured to pre-create all connection threads
(at startup time), presumably it should always be possible to make the
server with all *.tcl pages cached at least as fast as without, as
long as you have enough RAM. No?
Yep.
--
Don Baccus
Portland, O
On Mon, Feb 24, 2003 at 07:51:40PM -, Bas Scheffers wrote:
> Don Baccus said:
> > The bytecode cache caches the top-level code for the page itself, that
> > was the point.
> Cool. Question still remains which is faster, cached .tcl pages or a heavy
> master interpreter. Would be interesting to
Don Baccus said:
> The bytecode cache caches the top-level code for the page itself, that
> was the point.
Cool. Question still remains which is faster, cached .tcl pages or a heavy
master interpreter. Would be interesting to see. May have a play with that
over the next few weeks.
Bas.
I. To re
Bas Scheffers wrote:
(Tcl only compiles code likely to be reused, which is procs, I
expect the bytecode cache to do the same)
The bytecode cache caches the top-level code for the page itself, that
was the point.
--
Don Baccus
Portland, OR
http://donb.photo.net, http://birdnotes.net, http://openacs
Please make sure when submitting bugs or patches for AOLserver 4.x,
that you attribute them to one of the 4.x groups. The core team will be
discussing a better method for processing these at our next meeting
this week. Thanks!
- Nathan
On Monday, February 24, 2003, at 11:46 AM, Jamie Rasmussen wro
Jamie Rasmussen wrote:
5. The SourceForge versions of nscache, nsoracle, and nsxml are newer
than what OpenACS includes. We just need to check that OpenACS works
with them.
They do, but you can't virtual host two OpenACS 4.x sites currently
because nscache maintains one giant global cache for ev
AOLServer 4 + nspostgres, nsoracle, nscache and nsxml from sourceforge
all work fine with OpenACS 4.6. OpenACS 4.7 (cvs HEAD) needs some of the
i18n tcl API from the ad13 patches.
I. To remove yourself from this list:
Send a message to "[EMAIL PROTECTED]" with the following text in
the BODY o
I uploaded these files to SourceForge a few days ago as patch #689515.
I can't say if they actually improve performance or not. A few other
notes on the OpenACS/AD13 distribution vs. AOLserver 4 are below.
Please let me know if I'm missing anything!
1. AD13 has extra i18n-related Tcl procs in cha
> But has it been proven to be effective? I haven't seen any numbers. I
> helped implement it, but I don't recall that we (ArsDigita) ever did a
> serious analysis of whether it improved performance.
Personaly I doubt it, except when it is for massive pages with lots of
procs. (Tcl only compiles
Rob Mayoff wrote:
+-- On Feb 23, Don Baccus said:
The code's been used successfully in many sites so seems stable.
But has it been proven to be effective? I haven't seen any numbers. I
helped implement it, but I don't recall that we (ArsDigita) ever did a
serious analysis of whether it
+-- On Feb 23, Don Baccus said:
> The code's been used successfully in many sites so seems stable.
But has it been proven to be effective? I haven't seen any numbers. I
helped implement it, but I don't recall that we (ArsDigita) ever did a
serious analysis of whether it improved performa
The custom AOLserver distributed first by Ars Digita then by the OpenACS
project (AOLserver3.3+ad13 being the latest) included code to cache
bytecode produced when Tcl pages are compiled.
This hasn't made it into AOLserver 4.0, though ns_cache, upon which it
depends, has.
Was this intentional or an
19 matches
Mail list logo
