I do not think that this is the problem, really. I mean, not the
creation or disposal of *that* objects. The problem, if any, is
in the Tcl_FS* calls which do quite a bit of "arithmetic" to
fiddle with the internal path reps and stuff. It is this part that
*may* hit you. Again, if you have a test
I do not think that this is the problem, really. I mean, not the
creation or disposal of *that* objects. The problem, if any, is
in the Tcl_FS* calls which do quite a bit of "arithmetic" to
fiddle with the internal path reps and stuff. It is this part that
*may* hit you. Again, if you have a test
On 13.12.2006, at 17:11, Vlad Seryakov wrote:
Tcl_Obj needs to be created, then deallocated.
which is a fairly quick operation as it mostly just
removes the object from the per-thread list and puts
it back on that list when done.
Tcl_OpenFileChannel and other we use are obsolete in the Tcl
The parts i have doubts are those when Tcl file needs to be open or
something, Tcl_Obj needs to be created, then deallocated.
Tcl_OpenFileChannel and other we use are obsolete in the Tcl core
sources, internally, it creates String object and calls corresponding FS
calls. This is overhead if the
On 13.12.2006, at 16:54, Vlad Seryakov wrote:
Is it possible to have TclVfs code compile time or realtime
configurable?
I started that (configurable) way. Then we talked (I cannot recall
exactly when)
and decided to put it hard-wired all the time.
Instead of using direct open/read/writ
Zoran,
Is it possible to have TclVfs code compile time or realtime configurable?
Zoran Vasiljevic wrote:
On 12.12.2006, at 19:40, Stephen Deasey wrote:
Tcl not being the fastest kid on the block, and folklore saying you
should reboot your AOLserver/NaviServer once/day due to chronic memory
fr
