Re: [fossil-users] Latest MinGW does not need _USE_32BIT_TIME_T anymore

2014-02-24 Thread Jan Nijtmans
2014-02-21 13:56 GMT+01:00 Jan Nijtmans jan.nijtm...@gmail.com:
 I would say it's a GO. Any objections?


The Speed-up as suggested by Samuel Debionne is merged
to trunk now. I noticed considerable speedup on Windows and
Cygwin (up to 40%). I tested it on Ubuntu as well, but there
the speedup was not impressive, just a few %.

Thanks!
  Jan Nijtmans
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users


Re: [fossil-users] Latest MinGW does not need _USE_32BIT_TIME_T anymore

2014-02-21 Thread Jan Nijtmans
2014-02-21 12:40 GMT+01:00 Stephan Beal sgb...@googlemail.com:
 Not bad. Try ./fossil rebuild - that one does a lot more i/o (and is
 harmless unless you have added your own tables to the repo db).


That wouldn't help. This improvement is for accessing the local
checkout, fossil rebuild is not an operation touching that.

The only operations this is expected giving a speedup is
in fossil extra or fossil addremove:  Functions which
traverse the checked-out filesystem.

Regards,
   Jan Nijtmans
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users


Re: [fossil-users] Latest MinGW does not need _USE_32BIT_TIME_T anymore

2014-02-20 Thread Jan Nijtmans
2014-02-20 14:39 GMT+01:00 Samuel Debionne samuel.debio...@ujf-grenoble.fr:
 Hello all,

 Compiling Fossil with the latest MinGW32 (that includes MinGW Runtime 
 4.0) seems not to require _USE_32BIT_TIME_T.
 Actually Fossil builds without error but will crash at runtime with any
 commands that browses the filesystem tree (vfile_scan). This is because
 the definition of _wdirent in fossil and in mingw does not match (one
 using 32 bits time and the other 64 bits). This may be a regression of
 MinGW Runtime...

Did you try it on Windows XP too?  -D_USE_32BIT_TIME_T is needed to
stay compatible with Windows XP. Starting with Vista everything works.

Yes it's a regression in MinGW, see:
http://fossil-scm.org/index.html/tktview?name=18cff45a4e
and
https://sourceforge.net/p/mingw/bugs/2125/

Regards,
 Jan Nijtmans
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users


Re: [fossil-users] Latest MinGW does not need _USE_32BIT_TIME_T anymore

2014-02-20 Thread Jan Nijtmans
2014-02-20 14:46 GMT+01:00 Jan Nijtmans jan.nijtm...@gmail.com:
 2014-02-20 14:39 GMT+01:00 Samuel Debionne samuel.debio...@ujf-grenoble.fr:
 Hello all,

 Compiling Fossil with the latest MinGW32 (that includes MinGW Runtime 
 4.0) seems not to require _USE_32BIT_TIME_T.
 Yes it's a regression in MinGW, see:
 http://fossil-scm.org/index.html/tktview?name=18cff45a4e
 and
 https://sourceforge.net/p/mingw/bugs/2125/

 Regards,
  Jan Nijtmans


@Samuel, could you please as some comments to
MinGW's bug report here:
https://sourceforge.net/p/mingw/bugs/2106/
This MinGW bug already has 5 duplications, and it is
already open for more than 4 months. It's really time
they bring out a fix for it...

Thanks!
  Jan Nijtmans
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users


Re: [fossil-users] Latest MinGW does not need _USE_32BIT_TIME_T anymore

2014-02-20 Thread Samuel Debionne
Hello Jan,

 @Samuel, could you please as some comments to
 MinGW's bug report here:
 https://sourceforge.net/p/mingw/bugs/2106/
 This MinGW bug already has 5 duplications, and it is
 already open for more than 4 months. It's really time
 they bring out a fix for it...

With great pleasure ! And thanks to the pointers to those bug reports,
interesting reads indeed. If only I had found them before, that would
have saved my morning...

Samuel
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users


Re: [fossil-users] Latest MinGW does not need _USE_32BIT_TIME_T anymore

2014-02-20 Thread Samuel Debionne
While debugging vfile.c I noticed that vfile_scan does not use
dirent.d_type to dispatch between folder and regular file/link but
uses an addition getStat call. I came across this thread that claims a
high speedup for command like git status with this kind of optimization :

https://groups.google.com/forum/#!searchin/msysgit/d_type/msysgit/PGCFol99xUo/vjEPrajM_QsJ

Has this been ever considered ? Worth a try ?
Samuel
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users


Re: [fossil-users] Latest MinGW does not need _USE_32BIT_TIME_T anymore

2014-02-20 Thread Jan Nijtmans
2014-02-20 15:17 GMT+01:00 Samuel Debionne samuel.debio...@ujf-grenoble.fr:
 While debugging vfile.c I noticed that vfile_scan does not use
 dirent.d_type to dispatch between folder and regular file/link but
 uses an addition getStat call. I came across this thread that claims a
 high speedup for command like git status with this kind of optimization :

 https://groups.google.com/forum/#!searchin/msysgit/d_type/msysgit/PGCFol99xUo/vjEPrajM_QsJ

 Has this been ever considered ? Worth a try ?

See:
http://www.gnu.org/software/libc/manual/html_node/Directory-Entries.html

 This member is a BSD extension. The symbol _DIRENT_HAVE_D_TYPE is defined if 
 this member is available.
 On systems where it is used, it corresponds to the file type bits in the 
 st_mode member of struct stat.
 If the value cannot be determine the member value is DT_UNKNOWN

As far as I know it is never considered. I simply have no idea how
wide-spread it is.

Regards,
  Jan Nijtmans
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users


Re: [fossil-users] Latest MinGW does not need _USE_32BIT_TIME_T anymore

2014-02-20 Thread Jan Nijtmans
2014-02-20 15:17 GMT+01:00 Samuel Debionne samuel.debio...@ujf-grenoble.fr:
 While debugging vfile.c I noticed that vfile_scan does not use
 dirent.d_type to dispatch between folder and regular file/link but
 uses an addition getStat call. I came across this thread that claims a
 high speedup for command like git status with this kind of optimization :

 https://groups.google.com/forum/#!searchin/msysgit/d_type/msysgit/PGCFol99xUo/vjEPrajM_QsJ

 Has this been ever considered ? Worth a try ?

Something like:
 http://fossil-scm.org/index.html/info/0c7834c77b
?

It looks like _DIRENT_HAVE_D_TYPE is set for MSC
(win/include/dirent.h) and on WinGW-w64, but not bare
MinGW. I have no idea whether's it's worth or not.

Regards,
Jan Nijtmans
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users