[naviserver-devel] status of the three main early developers?
As I recall, Stephen Deasey, Zoran Vasiljevic, and Vlad Seryakov were the three developers who originally forked the Naviserver project from AOLserver 4.0.10 and then did nearly all of the subsequent work on it for years. But I haven't heard from them much lately. I'm curious, are they still actively using and working on Naviserver, or (like Jim Davidson), have they mostly moved on to other projects? -- Andrew Piskorski -- Slashdot TV. Videos for Nerds. Stuff that Matters. http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk ___ naviserver-devel mailing list naviserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/naviserver-devel
Re: [naviserver-devel] Naviserver hangs on Windows
On Mon, Oct 06, 2014 at 11:33:25PM +0100, Stephen wrote: > Here are some build errors while cross-compiling with mingw using this > docker image: > > https://bitbucket.org/groks/build-naviserver-mingw/src/tip/naviserver/ The docker image sounds useful. However, building with Mingw on Windows would use the Unix makefiles. I've never tested that build combination and doubt that anyone else has done so recently either. Right now I'm focused on just getting Windows builds to work with nmake and MSVC. Mingw can come later, especially since it (at least currently) and MSVC are tied to different build systems. It would be nice to eventually adopt a single build system that would work well with all combinations of platforms and compilers, but discussing that seems somewhat premature. Btw, the pages below on Tcl-based replacements for make and autoconf are interesting, especially in that it should be feasible to have **Tcl itself** self-host on such tools, while avoiding the chicken-and-egg problem: http://wiki.tcl.tk/27561 http://wiki.tcl.tk/27197 http://wiki.tcl.tk/12593 But I'd want get the opinion of the Tcl core team and other experts before going very far down such a path, either for Naviserver or in my own code. -- Andrew Piskorski -- Slashdot TV. Videos for Nerds. Stuff that Matters. http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk ___ naviserver-devel mailing list naviserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/naviserver-devel
Re: [naviserver-devel] Naviserver hangs on Windows
On Mon, Oct 6, 2014 at 10:31 PM, Gustaf Neumann wrote: > > I've merged in your changes to the main branch. Here are some build errors while cross-compiling with mingw using this docker image: https://bitbucket.org/groks/build-naviserver-mingw/src/tip/naviserver/ ---> 0eaa9093aff9 Removing intermediate container 4d4d06c9d5b4 Step 8 : RUN PATH=/usr/x86_64-w64-mingw32/sys-root/mingw/bin:$PATH make all build-doc \ INSTALL_ROOT="/" STRINGS=/usr/bin/x86_64-w64-mingw32-strings OBJCOPY=/usr/bin/x86_64-w64-mingw32-objcopy NM=/usr/bin/x86_64-w64-mingw32-nm DLLWRAP=/usr/bin/x86_64-w64-mingw32-dllwrap GCC=/usr/bin/x86_64-w64-mingw32-gcc WINDRES=/usr/bin/x86_64-w64-mingw32-windres ADDR2LINE=/usr/bin/x86_64-w64-mingw32-addr2line AS=/usr/bin/x86_64-w64-mingw32-as PKG_CONFIG=/usr/bin/x86_64-w64-mingw32-pkg-config CPP=/usr/bin/x86_64-w64-mingw32-cpp ELFEDIT=/usr/bin/x86_64-w64-mingw32-elfedit HOST_CC=gcc LD=/usr/bin/x86_64-w64-mingw32-ld DLLTOOL=/usr/bin/x86_64-w64-mingw32-dlltool AR=/usr/bin/x86_64-w64-mingw32-ar SIZE=/usr/bin/x86_64-w64-mingw32-size WINDMC=/usr/bin/x86_64-w64-mingw32-windmc GPROF=/usr/bin/x86_64-w64-mingw32-gprof RANLIB=/usr/bin/x86_64-w64-mingw32-ranlib CXXFILT=/usr/bin/x86_64-w64-mingw32-c++filt GCOV=/usr/bin/x86_64-w64-mingw32-gcov CC=x86_64-w64-mingw32-gcc READELF=/usr/bin/x86_64-w64-mingw32-readelf OBJDUMP=/usr/bin/x86_64-w64-mingw32-objdump STRIP=/usr/bin/x86_64-w64-mingw32-strip LD_BFD=/usr/bin/x86_64-w64-mingw32-ld.bfd ---> Running in ed1e545df7f9 make[1]: Entering directory `/usr/local/src/naviserver-tip/nsthread' x86_64-w64-mingw32-gcc -g -O2 -fomit-frame-pointer -Wall -pipe -I../include -I"/usr/local/tcl8.6.2-mingw/include" -DHAVE_CONFIG_H -c -o error.o error.c In file included from thread.h:40:0, from error.c:37: ../include/nsthread.h:168:0: warning: "lseek" redefined [enabled by default] # define lseek _lseek ^ In file included from ../include/nsthread.h:107:0, from thread.h:40, from error.c:37: /usr/x86_64-w64-mingw32/sys-root/mingw/include/io.h:335:0: note: this is the location of the previous definition #define lseek lseek64 ^ x86_64-w64-mingw32-gcc -g -O2 -fomit-frame-pointer -Wall -pipe -I../include -I"/usr/local/tcl8.6.2-mingw/include" -DHAVE_CONFIG_H -c -o master.o master.c In file included from thread.h:40:0, from master.c:36: ../include/nsthread.h:168:0: warning: "lseek" redefined [enabled by default] # define lseek _lseek ^ In file included from ../include/nsthread.h:107:0, from thread.h:40, from master.c:36: /usr/x86_64-w64-mingw32/sys-root/mingw/include/io.h:335:0: note: this is the location of the previous definition #define lseek lseek64 ^ x86_64-w64-mingw32-gcc -g -O2 -fomit-frame-pointer -Wall -pipe -I../include -I"/usr/local/tcl8.6.2-mingw/include" -DHAVE_CONFIG_H -c -o memory.o memory.c In file included from thread.h:40:0, from memory.c:36: ../include/nsthread.h:168:0: warning: "lseek" redefined [enabled by default] # define lseek _lseek ^ In file included from ../include/nsthread.h:107:0, from thread.h:40, from memory.c:36: /usr/x86_64-w64-mingw32/sys-root/mingw/include/io.h:335:0: note: this is the location of the previous definition #define lseek lseek64 ^ x86_64-w64-mingw32-gcc -g -O2 -fomit-frame-pointer -Wall -pipe -I../include -I"/usr/local/tcl8.6.2-mingw/include" -DHAVE_CONFIG_H -c -o mutex.o mutex.c In file included from thread.h:40:0, from mutex.c:36: ../include/nsthread.h:168:0: warning: "lseek" redefined [enabled by default] # define lseek _lseek ^ In file included from ../include/nsthread.h:107:0, from thread.h:40, from mutex.c:36: /usr/x86_64-w64-mingw32/sys-root/mingw/include/io.h:335:0: note: this is the location of the previous definition #define lseek lseek64 ^ x86_64-w64-mingw32-gcc -g -O2 -fomit-frame-pointer -Wall -pipe -I../include -I"/usr/local/tcl8.6.2-mingw/include" -DHAVE_CONFIG_H -c -o cslock.o cslock.c In file included from thread.h:40:0, from cslock.c:47: ../include/nsthread.h:168:0: warning: "lseek" redefined [enabled by default] # define lseek _lseek ^ In file included from ../include/nsthread.h:107:0, from thread.h:40, from cslock.c:47: /usr/x86_64-w64-mingw32/sys-root/mingw/include/io.h:335:0: note: this is the location of the previous definition #define lseek lseek64 ^ x86_64-w64-mingw32-gcc -g -O2 -fomit-frame-pointer -Wall -pipe -I../include -I"/usr/local/tcl8.6.2-mingw/include" -DHAVE_CONFIG_H -c -o rwlock.o rwlock.c In file included from thread.h:40:0, from rwlock.c:48: ../include/nsthread.h:168:0: w
Re: [naviserver-devel] Naviserver hangs on Windows
On 06.10.14 23:54, Andrew Piskorski wrote: > Is my "clean" branch helpful to you, or should I get rid of it? on the clone used for the pull request, it is easier, if no new branches are introduced (at least for me). Please something more to try: to provide some potential evidence for my "too early for tcl calls" hypothesis, i've deactivated for the time being the mutex time monitoring for windows, since the earliest calls are from mutex calls. Can you check when possible, whether Tcl_GetTime() can be used now inside Ns_GetTime()? -g -- Slashdot TV. Videos for Nerds. Stuff that Matters. http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk ___ naviserver-devel mailing list naviserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/naviserver-devel
Re: [naviserver-devel] Naviserver hangs on Windows
On Mon, Oct 06, 2014 at 11:31:27PM +0200, Gustaf Neumann wrote: > I've merged in your changes to the main branch. In order to keep > your change history, i merged the changes rather than copying the > files, but had at the end the problem to get rid the branch "clean", > since mercurial likes to keep branches around. Is my "clean" branch helpful to you, or should I get rid of it? I created that "clean" branch with that idea that you'd prefer to merge from it rather than from my "default" branch. But I'm new to Mercurial and not entirely sure how useful that really is. What I wanted is to have my "clean" branch be almost exactly the same as my "default", but with any Andy-specific hacks removed. So I branched clean, and then removed my rpath hack. (As we've previously discussed, I need that rpath hack to work on Linux, but it's clearly the wrong fix. I added it only because I don't understand where the true bug is coming from.) In Mercurial, it doesn't seem that easy to keep two branches SLIGHTLY different from each other. Apparently the recommended way to "cherry pick" changes is with "hg graft", but I did not try that, as it didn't seem like what I really wanted in this case. I'll see how it goes as I do more merges across my two branches, assuming I keep the "clean" branch around. -- Andrew Piskorski -- Slashdot TV. Videos for Nerds. Stuff that Matters. http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk ___ naviserver-devel mailing list naviserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/naviserver-devel
Re: [naviserver-devel] Naviserver hangs on Windows
On 06.10.14 20:15, Andrew Piskorski wrote:. Actually, and strangely, my Naviserver on Windows appeared to NEVER call gettimeofday() there, regardless of whether HAVE_GETTIMEOFDAY was true or false! I tried it both ways. I can't explain that; perhaps I was merely confused. Actually, the acronym coming out of configure is #ifdef HAVE_GETTIMEOFDAY ... #endif Note that the expression is true, no matter whether HAVE_GETTIMEOFDAY is set to 1 or 0 ... was that maybe the problem? But what is much more important to me, is that running the final "portable" Tcl-dependent code at the end definitely triggered a serious bug, making Naviserver unusable. The word "unusable" is a understatement. The problem here is, when the tcl library does not work, most likely other calls to the tcl library will probably fail as well. Maybe the problem is that functions of the tcl library are called to early, before it is initialized. I've merged in your changes to the main branch. In order to keep your change history, i merged the changes rather than copying the files, but had at the end the problem to get rid the branch "clean", since mercurial likes to keep branches around. when for the clock value for localtime_s() is valid, then the only problem might be the storage area, which is coming from the thread-local storage. Maybe localtime_s is not happy with the provided address. Switching the localtime() might work, but is only a fix for the symptoms. -g -- Slashdot TV. Videos for Nerds. Stuff that Matters. http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk___ naviserver-devel mailing list naviserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/naviserver-devel
Re: [naviserver-devel] Naviserver hangs on Windows
On Sun, Oct 05, 2014 at 09:37:39PM +0200, Maurizio Martignano wrote:
> > Did you use the define _USE_32BIT_TIME_T yes or not?
> I believe you should use it.
I haven't tried using _USE_32BIT_TIME_T yet, but I think using it
would be INCORRECT on Windows-64.
Tcl 8.5.16 does this in win/tclWinPort.h:
#ifndef _WIN64
/* See [Bug 3354324]: file mtime sets wrong time */
# define _USE_32BIT_TIME_T
#endif
So it does NOT set _USE_32BIT_TIME_T when _WIN64 is defined.
I assume _WIN64 is always defined for 64-bit Windows.
Relevant discussion appears to be here:
http://sourceforge.net/p/tcl/bugs/4845/
http://sourceforge.net/p/tcl/bugs/5115/
http://sourceforge.net/p/mingw/bugs/1973/
It looks to me like the horrible confusion about what should be done
is only for ** 32-bit ** Windows systems, especially when trying to
support multiple old and new versions of 32-bit Windows.
In contrast, 64-bit Windows seems straightforward. And I am on 64-bit
Windows now! So I think I should simply NEVER set "_USE_32BIT_TIME_T".
Does that sound right?
What does Tcl actually do, in practice, on 64-bit Linux and Window?
Here's a simple test, which shows that Tcl 8.5.x does indeed use a
64-bit time_t in both those cases, and that the integer values are
exactly the same on Windows and Linux, as they should be. That
corresponds to my understanding of the code above, that Tcl NEVER sets
_USE_32BIT_TIME_T on 64-bit Windows.
# On Windows 7 64-bit, running ActiveTcl 8.5:
% info patchlevel
8.5.15
% info nameofexecutable
C:/P/Tcl85/bin/tclsh85.exe
% info sharedlibextension
.dll
% set in_l [list {1970-01-01 00:00:00 GMT} {2038-12-01 00:00:00 GMT}
{-12-01 00:00:00 GMT}]
{1970-01-01 00:00:00 GMT} {2038-12-01 00:00:00 GMT} {-12-01 00:00:00 GMT}
% foreach ss $in_l { set tt [clock scan $ss] ; puts "$tt -> [clock format $tt
-gmt 1]" }
0 -> Thu Jan 01 00:00:00 GMT 1970
2174774400 -> Wed Dec 01 00:00:00 GMT 2038
253399622400 -> Wed Dec 01 00:00:00 GMT
% exit
# On Linux 64-bit, Ubuntu 12.04.3 LTS:
$ /usr/bin/tclsh8.5
% info patchlevel
8.5.11
% info nameofexecutable
/usr/bin/tclsh8.5
% info sharedlibextension
.so
% set in_l [list {1970-01-01 00:00:00 GMT} {2038-12-01 00:00:00 GMT}
{-12-01 00:00:00 GMT}]
{1970-01-01 00:00:00 GMT} {2038-12-01 00:00:00 GMT} {-12-01 00:00:00 GMT}
% foreach ss $in_l { set tt [clock scan $ss] ; puts "$tt -> [clock format $tt
-gmt 1]" }
0 -> Thu Jan 01 00:00:00 GMT 1970
2174774400 -> Wed Dec 01 00:00:00 GMT 2038
253399622400 -> Wed Dec 01 00:00:00 GMT
% exit
--
Andrew Piskorski
--
Slashdot TV. Videos for Nerds. Stuff that Matters.
http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk
___
naviserver-devel mailing list
naviserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/naviserver-devel
Re: [naviserver-devel] Naviserver hangs on Windows
On Mon, Oct 06, 2014 at 10:16:31AM -0700, Jeff Rogers wrote: > If there is not significant performance advantage to the > platform-specific optimized version of Ns_GetTime over the > platform-independent Tcl_GetTime, is it worth it to keep the optimized > version? It is very much worth it to me, at least for now, because: One, I don't understand how the invocation of the "platform-independent Tcl_GetTime" even works. There is never any explicit call to Tcl_GetTime nor any other Tcl function, and Tcl_GetTime does not appear on the call stack. The so-callled "optimized" code is easier to understand. Two, the current "platform-independent" approach locks up in my Windows build, while the old Windows-specific code that AOLserver used for many years does not. I do not know why this is, but I certainly will use the old Windows-specific code until I figure it out. -- Andrew Piskorski -- Slashdot TV. Videos for Nerds. Stuff that Matters. http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk ___ naviserver-devel mailing list naviserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/naviserver-devel
Re: [naviserver-devel] Naviserver hangs on Windows
On Sun, Oct 05, 2014 at 09:31:31PM +0200, Gustaf Neumann wrote: > On busy systems, Ns_GetTime() is one of the most > frequent calls, used e.g. for mutex timings, so this makes a difference. Yes, so it's better for performance reasons, like I said. You may have written that small paragraph of code from scratch, but it is still true that inside the ifdef you added, the code calling gettimeofday() is essentially identical to what AOLserver used for many years. This is all fine, I see no problems with that code. > What i did was to extend "configure" to look, if there is gettimeofday() Actually, and strangely, my Naviserver on Windows appeared to NEVER call gettimeofday() there, regardless of whether HAVE_GETTIMEOFDAY was true or false! I tried it both ways. I can't explain that; perhaps I was merely confused. But what is much more important to me, is that running the final "portable" Tcl-dependent code at the end definitely triggered a serious bug, making Naviserver unusable. > b) When Tcl_GetTime() is not working on your system than you have a >broken Tcl installation. Does this happen with your self-compiled tcl > version? I do not know whether Tcl_GetTime() is working correctly in ActiveTcl 8.5 on Windows 7 64-bit or not. I will try something to verify that. Right now all I can say for sure is that funny indirect way that Naviserver calls Tcl_GetTime() in Ns_GetTime() fails horribly on my Windows build. So far I've never compiled Tcl on Windows 7 myself. I may try that soon to help with the debugging, but so far I've been exclusing using ActiveTcl 8.5. I strongly suspect that ActiveTcl is compiled correctly, but perhaps I am somehow linking against it incorrectly, or using incompatible build options, or something like that. > >http://msdn.microsoft.com/en-us/library/a442x3ye.aspx > > > > The *tp and *clock values look like a correct time_t count of seconds > > since the Unix epoch. So perhaps something is wrong with the only > > other argument ther to localtime_s(): &tlsPtr->ltbuf > > The page you are citing contains the error conditions, when EINVAL > is returned. The first argument can't be NULL, so clock must be > invalid according to this information. No, the clock value is not invalid, I already checked that and it is a correct count of seconds since the Unix epoch. The problem must lie either in the other argument, or in something entirely separate and out of band (e.g., build options). > on this issue. Have you tried the suggestion of Maurizio concerning > > USE_32BIT_TIME_T? I have not tried using it yet, but maybe I should. Previously, I wasn't sure if Maurizio was recommending it or warning against it. (I see now that he recommends using it.) My previous experience with AOLserver 4.0.x on Windows was with 32-bit Windows, which would have natively used 32-bit time_t. So perhaps forcing my 64-bit build to use 32-bit time_t would be useful. -- Andrew Piskorski -- Slashdot TV. Videos for Nerds. Stuff that Matters. http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk ___ naviserver-devel mailing list naviserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/naviserver-devel
Re: [naviserver-devel] modules/tcl/ is empty, tcl/ is full
On Sun, Oct 05, 2014 at 08:01:13PM +0200, Gustaf Neumann wrote: > Am 02.10.14 23:40, schrieb Andrew Piskorski: > > > > Do we actually need the modules/tcl/ directory for anything now? > yes, we need it for installing site specific tcl library files. Ah, so presumably Naviserver's moving of its own files from modules/tcl/ into tcl/ was in order to keep the Navisever and site-specific tcl files separate. Ok, that makes sense. -- Andrew Piskorski -- Slashdot TV. Videos for Nerds. Stuff that Matters. http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk ___ naviserver-devel mailing list naviserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/naviserver-devel
Re: [naviserver-devel] NS_EXTERN set wrong on Windows?
On Sun, Oct 05, 2014 at 07:58:34PM +0200, Gustaf Neumann wrote: > the NS_EXPORT situation is a mess, not being able to write to the > log file in an error situation is not really an option. The way NS_EXPORT is defined twice, in two totally separate places, is indeed ugly, but AFAICT, after my one initial fix to it weeks ago, it hasn't actually had any impact on my attempts to get Naviserver working on Windows. > Rather than commenting out error messages, the better option is probably > to move the ns.h include to the end and add warning lines, since reentrant.c > contains no NS_EXTERN etc. AFAICT, it has NEVER worked to call Ns_Log from the reentrant.c file, not on Linux and not on Windows either. Never. Making it work would be nice, but is well out of scope of my current "fix Naviserver to it actually builds and runs on Windows" work. -- Andrew Piskorski -- Slashdot TV. Videos for Nerds. Stuff that Matters. http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk ___ naviserver-devel mailing list naviserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/naviserver-devel
Re: [naviserver-devel] Naviserver hangs on Windows
Gustaf Neumann wrote: > Am 06.10.14 06:46, schrieb Jeff Rogers: >> >> This struck me as an interesting optimization question, so I wrote a >> quick program to test it (attached). > This is not an interesting optimization question, since Tcl itself uses > gettimeofday() > (plus jumping around which might have a bad cache and locality > influence, and some > more copying). I think my underlying point was missed in the measurements. If there is not significant performance advantage to the platform-specific optimized version of Ns_GetTime over the platform-independent Tcl_GetTime, is it worth it to keep the optimized version? The penalty to be paid is in problems like the current one, where the windows build is for some reason having problems. On windows the function is delegating to Tcl_GetTime, but the system-specific bits confuse the issue. Your measurements are consistent and show the relative results I expected. Such is the benefit of real hardware :) They show a small advantage to Ns_GetTime over Tcl_GetTime, about 1.2%. This *is* a very frequently called function, but it is also pretty fast in any case. That's 1.2% of perhaps 5% (?? totally random guess) of overall request processing time. To me, that adds up to not a lot. A different takeaway from this benchmark is that if you are trying to wring every last bit of performance out of this call, it might be advantageous to define it as a macro (or use gcc/c99 inline declarations so it can be inlined and avoid the function call overhead and get to within a few instructions of the raw gettimeofday call (presumably you'll still need to copy the elements to the Ns_Time struct). -J > > One cannot expect a big difference. For better reliability, > i've increased the count. Below are 4 runs on openacs.org. > The native call is from 8% to 20% faster (the latter one most > probably due to external influences). The machine is a bare metal. > Numbers will vary depending on the OS. The faster the > system function gettimeofday() is, the bigger is the percentage > difference. > > -g > > gustafn@openacs:~$ ./tt > count: 1 > Tcl_GetTime:3858686 usec 0.04 per > Ns_GetTime:3811593 usec 0.04 per > gettimeofday:3561367 usec 0.04 per > gustafn@openacs:~$ ./tt > count: 1 > Tcl_GetTime:3858657 usec 0.04 per > Ns_GetTime:3824398 usec 0.04 per > gettimeofday:3563398 usec 0.04 per > gustafn@openacs:~$ ./tt > count: 1 > Tcl_GetTime:4351765 usec 0.04 per > Ns_GetTime:4024717 usec 0.04 per > gettimeofday:3594736 usec 0.04 per > gustafn@openacs:~$ ./tt > count: 1 > Tcl_GetTime:3864511 usec 0.04 per > Ns_GetTime:3831866 usec 0.04 per > gettimeofday:3541932 usec 0.04 per > > > > -- > Slashdot TV. Videos for Nerds. Stuff that Matters. > http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk > ___ > naviserver-devel mailing list > naviserver-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/naviserver-devel > -- Slashdot TV. Videos for Nerds. Stuff that Matters. http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk ___ naviserver-devel mailing list naviserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/naviserver-devel
Re: [naviserver-devel] Naviserver hangs on Windows
Am 06.10.14 06:46, schrieb Jeff Rogers: > > This struck me as an interesting optimization question, so I wrote a > quick program to test it (attached). This is not an interesting optimization question, since Tcl itself uses gettimeofday() (plus jumping around which might have a bad cache and locality influence, and some more copying). One cannot expect a big difference. For better reliability, i've increased the count. Below are 4 runs on openacs.org. The native call is from 8% to 20% faster (the latter one most probably due to external influences). The machine is a bare metal. Numbers will vary depending on the OS. The faster the system function gettimeofday() is, the bigger is the percentage difference. -g gustafn@openacs:~$ ./tt count: 1 Tcl_GetTime:3858686 usec 0.04 per Ns_GetTime:3811593 usec 0.04 per gettimeofday:3561367 usec 0.04 per gustafn@openacs:~$ ./tt count: 1 Tcl_GetTime:3858657 usec 0.04 per Ns_GetTime:3824398 usec 0.04 per gettimeofday:3563398 usec 0.04 per gustafn@openacs:~$ ./tt count: 1 Tcl_GetTime:4351765 usec 0.04 per Ns_GetTime:4024717 usec 0.04 per gettimeofday:3594736 usec 0.04 per gustafn@openacs:~$ ./tt count: 1 Tcl_GetTime:3864511 usec 0.04 per Ns_GetTime:3831866 usec 0.04 per gettimeofday:3541932 usec 0.04 per -- Slashdot TV. Videos for Nerds. Stuff that Matters. http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk ___ naviserver-devel mailing list naviserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/naviserver-devel
