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

2014-02-21 13:56 GMT+01:00 Jan Nijtmans : > 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

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

2014-02-21 12:43 GMT+01:00 Jan Nijtmans : > The only operations this is expected giving a speedup is > in "fossil extra" or "fossil addremove": Functions which > traverse the checked-out filesystem. Measured on Cygwin64, on checked-out/built fossil repo (mtime-changes=0). Original timing (curren

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

2014-02-21 12:40 GMT+01:00 Stephan Beal : > 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 touch

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

On Fri, Feb 21, 2014 at 11:56 AM, Samuel Debionne < samuel.debio...@ujf-grenoble.fr> wrote: > $./fossil extra > > without _DIRENT_HAVE_D_TYPE : 30s - x1.0 > with _DIRENT_HAVE_D_TYPE : 22s - x1.36 > > Nothing phenomenal but not bad neither, no ? > Not bad. Try "./fossil rebuild" - that one does a

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

> rebuild/deconstruct are very i/o intensive, and it might be easier > to see the degree of change in longer-running ops like those. I'm not very familiar with this commands... Here are some raw performance numbers. The repository is a new (empty) one where 10K of files are copied that are not ve

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

Le 20/02/2014 16:23, Jan Nijtmans a écrit : > 2014-02-20 15:17 GMT+01:00 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 claim

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

On Fri, Feb 21, 2014 at 9:18 AM, Samuel Debionne < samuel.debio...@ujf-grenoble.fr> wrote: > I'll give it a try and report some perf numbers for some commands on the > fossil repo: > fossil status > fossil extra > > Does that sound correct ? > rebuild/deconstruct are very i/o intensive, and it mi

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

> Something like: > > ? Yes, this is exactly what I had in mind. The thread on git suggest that a speedup from x2-x6 on Windows (because the file system and mingw support the d_type). I'll give it a try and report some perf numbers for s

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

2014-02-20 15:17 GMT+01:00 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"

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

2014-02-20 15:17 GMT+01:00 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"

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

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.goog

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

Hello Jan, > @Samuel, could you please as some comments to > MinGW's bug report here: > > 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 p

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

2014-02-20 14:46 GMT+01:00 Jan Nijtmans : > 2014-02-20 14:39 GMT+01:00 Samuel Debionne : >> 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: >

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

2014-02-20 14:39 GMT+01:00 Samuel Debionne : > 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

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

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