search for: 0major

...ile changed, 0 insertions(+), 0 deletions(-) create mode 100644 llvm/dummy bash-4.1$ /usr/bin/time git log --no-color -z --pretty=raw --show-notes --parents --boundary HEAD -- dummy > /dev/null 198.37user 0.40system 3:18.67elapsed 100%CPU (0avgtext+0avgdata 696456maxresident)k 0inputs+0outputs (0major+175765minor)pagefaults 0swaps But also when examining older files, here are some tests using the monorepo: bash-4.1$ git clone https://github.com/llvm/llvm-project.git llvm-project bash-4.1$ cd llvm-project bash-4.1$ /usr/bin/time git log --no-color -z --pretty=raw --show-notes --parents --boun...

...s) it may be possible but, again, it only speaks > about the relative sizes of LLVM/Cray's compiler. Ok, here are some hard numbers for empty builds: LLVM empty build: /usr/bin/time make -j16 4.32user 2.47system 0:03.21elapsed 211%CPU (0avgtext+0avgdata 13376maxresident)k 0inputs+0outputs (0major+671804minor)pagefaults 0swaps Cray empty build: /usr/bin/time make dynamic-developer -j16 2.88user 1.06system 0:04.94elapsed 79%CPU (0avgtext+0avgdata 64208maxresident)k 0inputs+0outputs (0major+184605minor)pagefaults 0swaps The Cray empty build includes some really horrendous shell script tricke...

Nico Weber <thakis at chromium.org> writes: > On Tue, Nov 1, 2011 at 3:09 PM, David A. Greene <greened at obbligato.org> wrote: >> Óscar Fuentes <ofv at wanadoo.es> writes: >> >>> Okay, we can get rid of recursive make. However, as pointed out >>> elsewhere, removing recursive make will not make a difference on the >>> LLVM build. What

On Tue, Nov 01, 2011 at 06:27:35PM -0500, David A. Greene wrote: > Here is actual data comparing an empty LLVM build done recursively (the > LLVM build) and non-recursively (the Cray build). > > See this? > > 0inputs+0outputs (0major+671804minor)pagefaults 0swaps > > vs. this? > > 0inputs+0outputs (0major+184605minor)pagefaults 0swaps > > That's I/O. Sorry to disappoint you, but no, this isn't I/O. You have just shown that a LLVM build touches more mmap'd pages. Joerg

...more) 1. Making a new 3 GB (1024 x 3megabytes blocks) file with dd needs 10.18 sec wallclock time: taskset 1 time dd if=/dev/zero bs=3M count=1024 of=~backes/xxxxx 1024+0 records in 1024+0 records out 0.00user 10.02system 0:10.18elapsed 98%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+187minor)pagefaults 0swaps 2. Repeating the same for 3 times: taskset 1 time dd if=/dev/zero bs=3M count=1024 of=~backes/xxxxx 1024+0 records in 1024+0 records out 0.00user 11.88system 1:05.26elapsed 18%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+187minor)pagefaults 0swaps ta...

greened at obbligato.org (David A. Greene) writes: > Ok, here are some hard numbers for empty builds: > > LLVM empty build: > /usr/bin/time make -j16 > 4.32user 2.47system 0:03.21elapsed 211%CPU (0avgtext+0avgdata 13376maxresident)k > 0inputs+0outputs (0major+671804minor)pagefaults 0swaps So your 16-way machine takes 2.5 times more than my 4-way cheap desktop... > Cray empty build: > /usr/bin/time make dynamic-developer -j16 > 2.88user 1.06system 0:04.94elapsed 79%CPU (0avgtext+0avgdata 64208maxresident)k > 0inputs+0outputs (0major+184605m...

Olly Betts writes: > On Sun, Apr 10, 2016 at 04:47:01PM +0200, Jean-Francois Dockes wrote: > > Some might notice the 50% index size increase. Excessive index size is > > already one relatively rare, but recurring complaint. Except if I did > > something wrong: I'm actually quite surprised by it. > > Did you try compacting the resulting databases? > >

...*******LIB***************** Tue Apr 12 10:43:14 CEST 2016 #define SEQ_START_POINT (-10) -rwxr-xr-x 1 root root 30728315 Apr 12 10:43 /usr/lib/libxapian-1.3.so.6 ************************* 452.68user 124.94system 4:42.27elapsed 204%CPU (0avgtext+0avgdata 1055204maxresident)k 0inputs+21046192outputs (0major+41137071minor)pagefaults 0swaps ************************* 793244 /home/dockes/.recoll/xapiandb total 793240 -rw-r--r-- 1 dockes dockes 24150016 Apr 12 10:47 docdata.glass -rw-r--r-- 1 dockes dockes 0 Apr 12 10:47 flintlock -rw-r--r-- 1 dockes dockes 130 Apr 12 10:47 iamglass -rw-r--r...

...return 0; } /************************************/ Then in R evaluate: > print.default (system.time (system(paste ("time", "bash -c './timer-test 100 > /dev/null'")))) 10.77user 0.02system 0:10.81elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+4574minor)pagefaults 0swaps user.self sys.self elapsed user.child sys.child 0.000 0.000 10.818 10.777 10.777 attr(,"class") [1] "proc_time" Expected: the sys.child time should be 0.02. > version _ plat...

...9}&done' to create one million files. my script and command are as bellows: walkerxk at tp:~/test.d$ ./test.sh &>test.log walkerxk at tp:~/test.d$ grep . d[12].log d1.log:1.89user 28.20system 13:40.39elapsed 3%CPU (0avgtext+0avgdata 77632maxresident)k d1.log:759808inputs+104outputs (0major+24631minor)pagefaults 0swaps d2.log:3.68user 36.77system 17:54.18elapsed 3%CPU (0avgtext+0avgdata 172128maxresident)k d2.log:630416inputs+48outputs (4major+11255minor)pagefaults 0swaps walkerxk at tp:~/test.d$ cat test.log ls: cannot access d1: No such file or directory 0 0 walkerxk at tp:~/test.d...

Hi, I don''t know if this has been discussed before, but have you thought about adding LZO compression to ZFS? One zfs-fuse user has provided a patch which implements LZO compression, and he claims better compression ratios *and* better speed than lzjb. The miniLZO library is licensed under the GPL, but the author specifically says that other licenses are available by request. Has this

...But it can do an adequate job given enough memory to work with. When I run your GitHub issue example on a machine with around 500 Gb of RAM it seems to run OK; /usr/bin/time reports 2706.89user 161.89system 37:10.65elapsed 128%CPU (0avgtext+0avgdata 92180796maxresident)k 0inputs+103450552outputs (0major+38716351minor)pagefaults 0swaps So the memory footprint is quite large. Using gc.time() it looks like about 1/3 of the time is in GC. Not ideal, and maybe could be improved on a bit, but probably not by much. The GC is basically doing an adequate job, given enough RAM. If you run this example on...

On 11/24/20 11:27 AM, Jan Gorecki wrote: > Thanks Bill for checking that. > It was my impression that warnings are raised from some internal > system calls made when quitting R. At that point I don't have much > control over checking the return status of those. > Your suggestion looks good to me. > > Tomas, do you think this could help? could this be implemented? I think