Menu
▾
▴
naviserver-devel
|
From: Mike <nee...@gm...> - 2006-07-12 19:00:22
|
Two unrelated questions... The project for which I am considering NS will have a dynamic and very large static part. There will be many very large (650MB) static files that people will download. It is hard for me to judge what the performance of serving these files with NS will be. Of course benchmarking would be the ideal route, however I have the pleasure of writing the code now, and the hardware for this project won't be purchased until a while from now. Should I use NS for the dynamic part and redirect the static requests to something like lighttpd, or can I rely on NS to handle such load without problems? Does there exist a caching mechanism for dynamically generated tcl/adp pages? If it does, where can I find docs for how it works/when the cache is invalidated? Does a mechanism exist to "reload" the tcl libraries on a live server? (please pardon all the questions, I'm just trying to get up to speed with what's in there) |
|
From: Vlad S. <vl...@cr...> - 2006-07-12 19:08:24
|
Some time ago i added writer feature to NS, when configured in nssock section as ns_param writerthreads 2 NS will create 5 threads that will perform serving large files to the clients leaving connection threads to do dynamic parts. Those writer threads are serving multiple connections at the same time using aync IO, so no big overhead. As for caching for adp, tcl, NS and AS do caching compiled ADP pages as well as compiled Tcl pages internally, you do not have to do anything except playing with config parameters that define cache size, see cachesize in ns/server/$server/adp section filecachesize in ns/server/$server section Mike wrote: > Two unrelated questions... > > The project for which I am considering NS will have a dynamic and very > large static part. There will be many very large (650MB) static files > that people will download. It is hard for me to judge what the > performance of serving these files with NS will be. Of course > benchmarking would be the ideal route, however I have the pleasure of > writing the code now, and the hardware for this project won't be > purchased until a while from now. Should I use NS for the dynamic > part and redirect the static requests to something like lighttpd, or > can I rely on NS to handle such load without problems? > > Does there exist a caching mechanism for dynamically generated tcl/adp > pages? If it does, where can I find docs for how it works/when the > cache is invalidated? > > Does a mechanism exist to "reload" the tcl libraries on a live server? > > (please pardon all the questions, I'm just trying to get up to speed > with what's in there) > > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > naviserver-devel mailing list > nav...@li... > https://lists.sourceforge.net/lists/listinfo/naviserver-devel > -- Vlad Seryakov 571 262-8608 office vl...@cr... http://www.crystalballinc.com/vlad/ |
|
From: Mike <nee...@gm...> - 2006-07-12 19:15:13
|
On 7/12/06, Vlad Seryakov <vl...@cr...> wrote: > Some time ago i added writer feature to NS, when configured in nssock > section as > ns_param writerthreads 2 > > NS will create 5 threads that will perform serving large files to the > clients leaving connection threads to do dynamic parts. Those writer > threads are serving multiple connections at the same time using aync IO, > so no big overhead. is 5 vs 2 a typo...? Also, what constitutes "large files" in this situation - is it the "writersize" argument, or is there something else? I am nor sure how "async IO" compares to sendfile(2) - can you please comment on this? > > Does a mechanism exist to "reload" the tcl libraries on a live server? what I mean by this is not the cache - but the initial tcl library loaded at server startup. I would like to know if it's possible to somehow reload this without shutting down the entire web server. |
|
From: Vlad S. <vl...@cr...> - 2006-07-12 19:24:48
|
> > is 5 vs 2 a typo...? Also, what constitutes "large files" in this > situation - is it the "writersize" argument, or is there something > else? I am nor sure how "async IO" compares to sendfile(2) - can you > please comment on this? Typo, Yes, writersize define the size of the file should be greater than this, then writer thread will use it for sending. Async IO i mean, writer thread does loop and sends as much as possible chunks from the files, same way as driver thread reads multiple chunks of requests from multiple clients. sendfile blocks, so you will need 10 threads for 10 clients at the same time, in case of writer thread, it can alone transfer 10 files to 10 clients. May be it will be slower in each single case comparing to sendfile but overall it does it fast enough. >>> Does a mechanism exist to "reload" the tcl libraries on a live server? > > what I mean by this is not the cache - but the initial tcl library > loaded at server startup. I would like to know if it's possible to > somehow reload this without shutting down the entire web server. > > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > naviserver-devel mailing list > nav...@li... > https://lists.sourceforge.net/lists/listinfo/naviserver-devel > -- Vlad Seryakov 571 262-8608 office vl...@cr... http://www.crystalballinc.com/vlad/ |
|
From: Mike <nee...@gm...> - 2006-07-12 19:40:57
|
> Async IO i mean, writer thread does loop and sends as much as possible > chunks from the files, same way as driver thread reads multiple chunks > of requests from multiple clients. sendfile blocks, so you will need 10 > threads for 10 clients at the same time, in case of writer thread, it > can alone transfer 10 files to 10 clients. May be it will be slower in > each single case comparing to sendfile but overall it does it fast enough. Vlad, Sorry, but your assertion is not correct. sendfile() is not required to block - as far as I am aware it works on non-blocking sockets without a problem. The key advantages of using sendfile is that it is implemented zero-copy and allows the OS to do large-block read-ahead on the files. If serving 100 clients 650MB files, using non-blocking IO read+write needs to allocate local buffers. If buffers are small (e.g. 100KB) then the disk has to seek like crazy from file to file, and that will kill performance. If the buffers are large (e.g. 16MB) then the disk seek will be fine but I will need to burn 1.6GB of RAM for the buffers in the NS process... How does NS decide what this buffer size is? Can you point me at the code that performs this operation? How challenging would it be to add optional sendfile support here? |
|
From: Vlad S. <vl...@cr...> - 2006-07-12 19:26:22
|
> > what I mean by this is not the cache - but the initial tcl library > loaded at server startup. I would like to know if it's possible to > somehow reload this without shutting down the entire web server. > check ns_ictl command, it can do it -- Vlad Seryakov 571 262-8608 office vl...@cr... http://www.crystalballinc.com/vlad/ |
|
From: Vlad S. <vl...@cr...> - 2006-07-12 19:46:59
|
I could be wrong, never used sendfile before. The code you can check is driver.c, WriterThread, and bufsize parameter can be used to define buffer. I was considering using mmap, but somewhere i heard that too many mmapped files could be a problem for the server. Mike wrote: >> Async IO i mean, writer thread does loop and sends as much as possible >> chunks from the files, same way as driver thread reads multiple chunks >> of requests from multiple clients. sendfile blocks, so you will need 10 >> threads for 10 clients at the same time, in case of writer thread, it >> can alone transfer 10 files to 10 clients. May be it will be slower in >> each single case comparing to sendfile but overall it does it fast enough. > > Vlad, > Sorry, but your assertion is not correct. sendfile() is not required > to block - as far as I am aware it works on non-blocking sockets > without a problem. The key advantages of using sendfile is that it is > implemented zero-copy and allows the OS to do large-block read-ahead > on the files. If serving 100 clients 650MB files, using non-blocking > IO read+write needs to allocate local buffers. If buffers are small > (e.g. 100KB) then the disk has to seek like crazy from file to file, > and that will kill performance. If the buffers are large (e.g. 16MB) > then the disk seek will be fine but I will need to burn 1.6GB of RAM > for the buffers in the NS process... How does NS decide what this > buffer size is? Can you point me at the code that performs this > operation? How challenging would it be to add optional sendfile > support here? > > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > naviserver-devel mailing list > nav...@li... > https://lists.sourceforge.net/lists/listinfo/naviserver-devel > -- Vlad Seryakov 571 262-8608 office vl...@cr... http://www.crystalballinc.com/vlad/ |
|
From: Andrew P. <at...@pi...> - 2006-07-12 19:52:16
|
On Wed, Jul 12, 2006 at 03:00:17PM -0400, Mike wrote: > Of course benchmarking would be the ideal route, however I have the > pleasure of writing the code now, and the hardware for this project > won't be purchased until a while from now. Why do you need special hardware to run you benchmark? Just run it on your desktop or whatever other Linux box you have available to you. That should give be enough to at least get you started. -- Andrew Piskorski <at...@pi...> http://www.piskorski.com/ |
|
From: Andrew P. <at...@pi...> - 2006-07-12 19:57:30
|
On Wed, Jul 12, 2006 at 03:00:17PM -0400, Mike wrote: > Subject: [naviserver-devel] Questions about NS details... (scalability, lib changes) > Does there exist a caching mechanism for dynamically generated tcl/adp > pages? If it does, where can I find docs for how it works/when the > cache is invalidated? Yes, but last I heard no one got around to actually forward porting it from AOLserver 3.3+ad13 to 4.x: Cache compiled Tcl page bytecode https://sourceforge.net/tracker/?func=detail&aid=689515&group_id=3152&atid=353152 -- Andrew Piskorski <at...@pi...> http://www.piskorski.com/ |
|
From: Bernd E. <eid...@we...> - 2006-07-12 20:00:21
|
Hi Mike, > The project for which I am considering NS will have a dynamic and very > large static part. There will be many very large (650MB) static files > that people will download. It is hard for me to judge what the > performance of serving these files with NS will be. It depends a little bit on what is "a dynamic" and a "very large static part" and about what dimensions you talk in general. Usually it could make sense to delegate uncached, personalized, database intensive scripting parts to NS and the huge downloads to one or more (balanced) servers with very optimized capabilities in that context. "Pound" is very good for that (and brings SSL!, if you don't want to rely on the availability of nsopenssl). (And so the connections to the database on another server do not suffer from the downloads). Personally, if only authorized people should be allowed to download, it could be very easy (in terms of development) to do everything with n-Naviservers and one database simply because you limit the number of technologies you have to deal with. How many users will download? What minimum download rate do you want to offer them? You could limit the parallel number of downloads per box so you are able to come very close to the hardware dimensions needed. > Of course > benchmarking would be the ideal route, however I have the pleasure of > writing the code now, and the hardware for this project won't be > purchased until a while from now. Should I use NS for the dynamic > part and redirect the static requests to something like lighttpd, or > can I rely on NS to handle such load without problems? NS can handle it and offers specialized "writerthreads", but for the mere "dumb" transfer lighttpd might be a very good decision. Use NS for the scripting. > Does a mechanism exist to "reload" the tcl libraries on a live server? Yes, the "evil ns_eval". And you can activate the "lazyloader" mechanism that speeds up thread creation as only needed code parts are loaded via the unknown mechanism during the thread livetime. http://naviserver.sourceforge.net/wiki/index.php/Nstrace.tcl Bernd. |
|
From: Vlad S. <vl...@cr...> - 2006-07-12 20:02:31
|
Naviserver does it automatically, it was ported a long time ago Andrew Piskorski wrote: > On Wed, Jul 12, 2006 at 03:00:17PM -0400, Mike wrote: >> Subject: [naviserver-devel] Questions about NS details... (scalability, lib changes) > >> Does there exist a caching mechanism for dynamically generated tcl/adp >> pages? If it does, where can I find docs for how it works/when the >> cache is invalidated? > > Yes, but last I heard no one got around to actually forward porting it > from AOLserver 3.3+ad13 to 4.x: > > Cache compiled Tcl page bytecode > https://sourceforge.net/tracker/?func=detail&aid=689515&group_id=3152&atid=353152 > -- Vlad Seryakov 571 262-8608 office vl...@cr... http://www.crystalballinc.com/vlad/ |
|
From: Andrew P. <at...@pi...> - 2006-07-12 20:32:57
|
On Wed, Jul 12, 2006 at 04:03:37PM -0400, Vlad Seryakov wrote: > Naviserver does it automatically, it was ported a long time ago Awesome, that's good to know. > > Cache compiled Tcl page bytecode > > https://sourceforge.net/tracker/?func=detail&aid=689515&group_id=3152&atid=353152 -- Andrew Piskorski <at...@pi...> http://www.piskorski.com/ |
|
From: Stephen D. <sd...@gm...> - 2006-07-13 19:44:19
|
On 7/12/06, Andrew Piskorski <at...@pi...> wrote:
> On Wed, Jul 12, 2006 at 04:03:37PM -0400, Vlad Seryakov wrote:
> > Naviserver does it automatically, it was ported a long time ago
>
> Awesome, that's good to know.
>
It doesn't actually...
Byte code can only be cached per-interp and our caches are
server-wide. Currently, it's just caching the read of the Tcl source
from disk.
I think the way to go here is to merge Tcl pages in with the ADP page
code. What's the difference between an ADP page like this:
<%
# Entire page is Tcl...
%>
...and a *.tcl page under the page root? Nothing, practically.
They're both 'ADP pages' with one Tcl chunk.
The ADP stuff in aolserver 4.5 has *output* caching. Tcl pages would
be able to take advantage of output caching if they were just
one-chunk ADP pages.
This is on my todo list, but not for a while, so this might make a
nice project for someone. Someone needs to write a few tests for the
ADP stuff first -- aolserver seems to have broken the ADP stuff during
development. A nice small project for someone...
|
|
From: Vlad S. <vl...@cr...> - 2006-07-13 19:48:32
|
I meant .tcl file cacheing, which is in tcl/file.tcl when enabletclpages=on then all requests to .tcl are cached in global cache. Stephen Deasey wrote: > On 7/12/06, Andrew Piskorski <at...@pi...> wrote: >> On Wed, Jul 12, 2006 at 04:03:37PM -0400, Vlad Seryakov wrote: >>> Naviserver does it automatically, it was ported a long time ago >> Awesome, that's good to know. >> > > It doesn't actually... > > Byte code can only be cached per-interp and our caches are > server-wide. Currently, it's just caching the read of the Tcl source > from disk. > > I think the way to go here is to merge Tcl pages in with the ADP page > code. What's the difference between an ADP page like this: > > <% > # Entire page is Tcl... > %> > > ...and a *.tcl page under the page root? Nothing, practically. > They're both 'ADP pages' with one Tcl chunk. > > The ADP stuff in aolserver 4.5 has *output* caching. Tcl pages would > be able to take advantage of output caching if they were just > one-chunk ADP pages. > > This is on my todo list, but not for a while, so this might make a > nice project for someone. Someone needs to write a few tests for the > ADP stuff first -- aolserver seems to have broken the ADP stuff during > development. A nice small project for someone... > > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > naviserver-devel mailing list > nav...@li... > https://lists.sourceforge.net/lists/listinfo/naviserver-devel > -- Vlad Seryakov 571 262-8608 office vl...@cr... http://www.crystalballinc.com/vlad/ |
|
From: Stephen D. <sd...@gm...> - 2006-07-13 19:56:48
|
On 7/13/06, Vlad Seryakov <vl...@cr...> wrote: > I meant .tcl file cacheing, which is in tcl/file.tcl when > enabletclpages=on then all requests to .tcl are cached in global cache. Right, the Tcl is read from disk and cached in memory. But only the Tcl *source*. It needs to be byte code compiled before use. This is what Andrew is talking about. Our cache stringifys everything that goes into it -- you can't share Tcl objects between threads. Therefore, every time you retrieve the Tcl page from cache (not disk), you still have to byte code compile it. aolserver3.x-ad13 cached the byte code per-interp. |
|
From: Andrew P. <at...@pi...> - 2006-07-13 20:08:18
|
On Thu, Jul 13, 2006 at 08:44:17PM +0100, Stephen Deasey wrote: > Byte code can only be cached per-interp and our caches are > server-wide. Currently, it's just caching the read of the Tcl source > from disk. I thought the way Rob Mayoff's original feature worked was that it "compiled" *.tcl pages to Tcl procs, then cached the compiled bytecode of those procs, presumably in per-thread caches. Does that sound right? What happens for ordinary Tcl procs in ordinary Naviserver Tcl libraries? When do they get compiled to bytecode, and how does Naviserver avoid constantly recompiling them? Btw, is the byte code for a given Tcl snippet actually different somehow for Tcl interps in different conn threads? > I think the way to go here is to merge Tcl pages in with the ADP page > code. What's the difference between an ADP page like this: What would that accomplish? Is there already cacheing of the bytecodes of Tcl source included in ADP pages? > The ADP stuff in aolserver 4.5 has *output* caching. Tcl pages would Huh? Caching of the output generated by Tcl code is totally different than cacheing the compiled Tcl bytecodes. Both are useful, neither is a replacement for the other. -- Andrew Piskorski <at...@pi...> http://www.piskorski.com/ |
|
From: Stephen D. <sd...@gm...> - 2006-07-13 20:28:02
|
On 7/13/06, Andrew Piskorski <at...@pi...> wrote: > On Thu, Jul 13, 2006 at 08:44:17PM +0100, Stephen Deasey wrote: > > > Byte code can only be cached per-interp and our caches are > > server-wide. Currently, it's just caching the read of the Tcl source > > from disk. > > I thought the way Rob Mayoff's original feature worked was that it > "compiled" *.tcl pages to Tcl procs, then cached the compiled bytecode > of those procs, presumably in per-thread caches. Does that sound > right? No. Tcl code is compiled by running it. It's is compiled on demand. Except... Rob found a neat way to cheat by passing the script as an arg to a do-nothing 'for' command. 'for' compiles the script for you. Very smart and hellish to read... > What happens for ordinary Tcl procs in ordinary Naviserver Tcl > libraries? When do they get compiled to bytecode, and how does > Naviserver avoid constantly recompiling them? They're compiled when they're first called. Remember, the naviserver threading model is to run Tcl interps in different threads. This is the only way to do it as that's the only promise of thread safety Tcl provides. Everything else needs special treatment, hence the nsv_ interface which communicates between interps. So, if you have one virtual server defined, and 10 threads, each proc will be compiled 10 times, one each for each interp run by a conn thread. (and again for sched threads, jobs threads, etc.). The byte code is reused after that of course, unless the string representation of a proc changes, i.e. you redefine it. > Btw, is the byte code for a given Tcl snippet actually different > somehow for Tcl interps in different conn threads? Yes. The should be equal, but were compiled individually from separate copies of the source. > > I think the way to go here is to merge Tcl pages in with the ADP page > > code. What's the difference between an ADP page like this: > > What would that accomplish? Is there already cacheing of the > bytecodes of Tcl source included in ADP pages? Yes. And also, the bit below... > > The ADP stuff in aolserver 4.5 has *output* caching. Tcl pages would > > Huh? Caching of the output generated by Tcl code is totally different > than cacheing the compiled Tcl bytecodes. Both are useful, neither is > a replacement for the other. Right, output caching is a different thing. But wouldn't it be cool to have it working for ADP pages, Tcl pages, registered procs etc.? I don't want to implement that 3 separate times. |
|
From: Andrew P. <at...@pi...> - 2006-07-13 20:53:53
|
On Thu, Jul 13, 2006 at 09:28:00PM +0100, Stephen Deasey wrote: > Except... Rob found a neat way to cheat by passing the script as an > arg to a do-nothing 'for' command. 'for' compiles the script for you. > Very smart and hellish to read... Ok, some Tcl commands cause their script arguments to be compiled to bytecode, others simply interpret them directly. And Tcl interps automatically cache their own bytecode as necessary. So... Are you saying that Rob changed AOLserver 3.x such that it used 'for' rather than 'eval' (or whatever else) to run the code in *.tcl files? And THAT made all the difference, because as long as the *.tcl file had not changed, the Tcl interp would automatically find and use the bytecode it had already created the first time that particular *.tcl file was run? But if that's the case, then what does any of this have to do with per-thread caches? As you said, Naviserver is already cacheing the string source of *.tcl pages, so what's preventing you from using the same for/eval trick Rob used, for each interp? (I must be missing something here...) > > > I think the way to go here is to merge Tcl pages in with the ADP page > > > code. What's the difference between an ADP page like this: > > > > What would that accomplish? Is there already cacheing of the > > bytecodes of Tcl source included in ADP pages? > > Yes. And also, the bit below... > Right, output caching is a different thing. But wouldn't it be cool > to have it working for ADP pages, Tcl pages, registered procs etc.? Yes, indeed it would... -- Andrew Piskorski <at...@pi...> http://www.piskorski.com/ |
|
From: Zoran V. <zv...@ar...> - 2006-07-13 21:03:05
|
Am 13.07.2006 um 22:53 schrieb Andrew Piskorski: > >> Right, output caching is a different thing. But wouldn't it be cool >> to have it working for ADP pages, Tcl pages, registered procs etc.? > > Yes, indeed it would... Do not forget that you get caching for free if you just move bulk of the code in Tcl procedures. First time they are run, they get byte-compiled. Just my 2 cents. Cheers Zoran |
|
From: Andrew P. <at...@pi...> - 2006-07-13 21:08:16
|
On Thu, Jul 13, 2006 at 04:53:51PM -0400, Andrew Piskorski wrote: > On Thu, Jul 13, 2006 at 09:28:00PM +0100, Stephen Deasey wrote: > > > Except... Rob found a neat way to cheat by passing the script as an > > arg to a do-nothing 'for' command. 'for' compiles the script for you. > > Very smart and hellish to read... > But if that's the case, then what does any of this have to do with > per-thread caches? As you said, Naviserver is already cacheing the > string source of *.tcl pages, so what's preventing you from using the > same for/eval trick Rob used, for each interp? > (I must be missing something here...) Oh, the snippet of file.tcl Vlad posted talked about: bytecode, which will be associated with the Tcl_Obj we just cached (as its internal representation). Which maybe answers my question... I suspect that: The Tcl interp is able to cache and re-use the bytecode for procs, because the proc persists - its Tcl_Obj hangs around. But if you hand the Tcl interp a script snippet (e.g., the entire contents of a *.tcl page), yes a Tcl_Obj is created, but as soon as you're done evaluating the script, that Tcl_Obj's reference count drops to zero and it goes away. Thus there is no persistent Tcl_Obj around to hang the byte code internal-rep on unless you explicitly create one. And, Rob used a per-thread (or per-interp?) ns_cache to create that persistent Tcl_Obj. Something like that? Could a Tcl namespace variable of some sort also be used to provide the persistant Tcl_Obj for the *.tcl script? -- Andrew Piskorski <at...@pi...> http://www.piskorski.com/ |
|
From: Andrew P. <at...@pi...> - 2006-07-13 21:10:35
|
On Thu, Jul 13, 2006 at 05:08:14PM -0400, Andrew Piskorski wrote: > Which maybe answers my question... I suspect that: Doh, never mind my silly speculations, Stephen just explained now it really works in his last post. -- Andrew Piskorski <at...@pi...> http://www.piskorski.com/ |
|
From: Vlad S. <vl...@cr...> - 2006-07-13 21:17:08
|
You are right and now i see that Naviserver does not do this right because our global cache keeps strings only. It looks like waste of resource now caching file contents only but ns_share uses Tcl_Objs internally, so it is possible to use it instead maybe? Andrew Piskorski wrote: > On Thu, Jul 13, 2006 at 04:53:51PM -0400, Andrew Piskorski wrote: >> On Thu, Jul 13, 2006 at 09:28:00PM +0100, Stephen Deasey wrote: >> >>> Except... Rob found a neat way to cheat by passing the script as an >>> arg to a do-nothing 'for' command. 'for' compiles the script for you. >>> Very smart and hellish to read... > >> But if that's the case, then what does any of this have to do with >> per-thread caches? As you said, Naviserver is already cacheing the >> string source of *.tcl pages, so what's preventing you from using the >> same for/eval trick Rob used, for each interp? >> (I must be missing something here...) > > Oh, the snippet of file.tcl Vlad posted talked about: > > bytecode, which will be associated with the Tcl_Obj we just cached > (as its internal representation). > > Which maybe answers my question... I suspect that: > > The Tcl interp is able to cache and re-use the bytecode for procs, > because the proc persists - its Tcl_Obj hangs around. But if you hand > the Tcl interp a script snippet (e.g., the entire contents of a *.tcl > page), yes a Tcl_Obj is created, but as soon as you're done evaluating > the script, that Tcl_Obj's reference count drops to zero and it goes > away. Thus there is no persistent Tcl_Obj around to hang the byte > code internal-rep on unless you explicitly create one. And, Rob used > a per-thread (or per-interp?) ns_cache to create that persistent > Tcl_Obj. Something like that? > > Could a Tcl namespace variable of some sort also be used to provide > the persistant Tcl_Obj for the *.tcl script? > -- Vlad Seryakov 571 262-8608 office vl...@cr... http://www.crystalballinc.com/vlad/ |
|
From: Zoran V. <zv...@ar...> - 2006-07-13 21:26:41
|
Am 13.07.2006 um 23:18 schrieb Vlad Seryakov: > You are right and now i see that Naviserver does not do this right > because our global cache keeps strings only. It looks like waste of > resource now caching file contents only but ns_share uses Tcl_Objs > internally, so it is possible to use it instead maybe? As I said: if you move bytecodes from interp to interp, they get recompiled. The only way you can do that (bytecode cachbing) is to keep it in the same thread and interp and this is what Tcl procedures are already doing. Storing Tcl-Ojb in cache makes sense only if the internal rep does not get changed. In case of bytecodeds this will mostly happen. Cheers Zoran |
|
From: Stephen D. <sd...@gm...> - 2006-07-13 21:40:06
|
On 7/13/06, Zoran Vasiljevic <zv...@ar...> wrote: > > Am 13.07.2006 um 23:18 schrieb Vlad Seryakov: > > > You are right and now i see that Naviserver does not do this right > > because our global cache keeps strings only. It looks like waste of > > resource now caching file contents only but ns_share uses Tcl_Objs > > internally, so it is possible to use it instead maybe? > > As I said: if you move bytecodes from interp to interp, they > get recompiled. The only way you can do that (bytecode cachbing) > is to keep it in the same thread and interp and this is what > Tcl procedures are already doing. > Right, I forgot about that. I asked about this on the Tcl list a couple of years ago... When an object is byte-code compiled it's environment is taken into account, and that affects the compiled code. For example, many of the built-in Tcl commands now get inlined: for, while etc. But what if they've been redefined by user code? If you byte-code compile some code in one environment, then try to run it in another, it may not work if the environments are different. So the Tcl core detects and prevents this. All code is recompiled the first time it is run in a new environment. I was suggesting that maybe there should be a away around this as in some cases, like ours, we specifically make sure that all interps are identical: we create one master interp at start up and then clone it for each new thread. No one seemed excited by this though... |
|
From: Zoran V. <zv...@ar...> - 2006-07-14 08:42:52
|
Am 13.07.2006 um 23:40 schrieb Stephen Deasey: > > I was suggesting that maybe there should be a away around this as in > some cases, like ours, we specifically make sure that all interps are > identical: we create one master interp at start up and then clone it > for each new thread. No one seemed excited by this though... You can't do that, as when you compile: set a 1 in intrep A and interp B the "1" will result in different literal object so bytecode rep must be recompiled anyways. Even if you have one thread and several interps, each time the compiled bytecode object gets evaluated in the different interp, it gets recompiled. Therefore I would suggest people who need last microsecond of performance to put most of the frequently used code in procedures. Cheers Zoran |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X