similar to: monorepo: bad performance when using gitk / git log

Óscar Fuentes <ofv at wanadoo.es> writes: > 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

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.

Full_Name: Manuel L?pez-Ib??ez Version: R version 2.6.2 (2008-02-08) OS: linux-gnu Submission from: (NULL) (164.15.10.156) This is only relevant for CPU intensive child processes. Otherwise, the problem is not obvious. Therefore, we need a CPU intensive program like this one: /************************************/ /*** Compile with: gcc -o timer-test -O0 timer-test.c -lm */ #include

Hi, I'm running centos-4.4 on an SMP system with 4 dual core opterons (2.4 GHz), and 16 GB memory. The disk drives are 500 GB SATA-Drives. Wondering about times for dd command performance and rm command performance in an empty machine (the filesystem has been made with "mkfs.ext3 /dev/sd...", nothing more) 1. Making a new 3 GB (1024 x 3megabytes blocks) file with dd needs 10.18

Hi there. First of all, I'd like to congratulate to developers for making a free specification and LGPLed decoder/encoder. :-). I did some test, ripping 17 tracks of my CD and converting them to both MP3 and OGG format. MP3 encoder/player was Lame 3.70 OGG encoder/player was from a Saturday nightly tgz package. ------------------------------------ MP3: LAME-3.70 mpg123-0.59r-4 MP3: lame -S

Hi there. First of all, I'd like to congratulate to developers for making a free specification and LGPLed decoder/encoder. :-). I did some test, ripping 17 tracks of my CD and converting them to both MP3 and OGG format. MP3 encoder/player was Lame 3.70 OGG encoder/player was from a Saturday nightly tgz package. ------------------------------------ MP3: LAME-3.70 mpg123-0.59r-4 MP3: lame -S

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

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? > >

On Tue, 24 Nov 2020, Jan Gorecki wrote: > As for other calls to system. I avoid calling system. In the past I > had some (to get memory stats from OS), but they were failing with > exactly the same issue. So yes, if I would add call to system before > calling quit, I believe it would fail with the same error. > At the same time I think (although I am not sure) that new allocations

I got used to rsync's -v --progress option so much that I used it instead of rcp even to simply copy files across the network. I dont like software that doesnt talk to me! :-) I like the percentage bar that --progress gives! To my surprise, I found that, when dealing with 1GB+ files, rsync is 4-5 _times_ slower than rcp. Yes, I know that rsync is optimized for sending deltas to a file

...but 2.4.3 worked fine. this is linux 2.4.18 with glibc 2.2.5 and libz 1.1.4, if it matters, on both source and dest. apparently something about trying to send a file ending with .iso gives rsync a fit if the -z [compress] option is used. $ time rsync -Pzv --stats cd1_en_binary.iso mail.cheek.com::root/home/ericom Password: cd1_en_binary.iso rsync: error writing 16385 unbuffered bytes -

Olly Betts writes: > On Mon, Apr 11, 2016 at 09:54:36AM +0200, Jean-Francois Dockes wrote: > > The question which remains for me is if I should run xapian-compact > > after an initial indexing operation. I guess that this depends on the > > amount of expected updates and that there is no easy answer ? > > I think it's not obvious whether it's a good plan

Well, maybe this is sort of related... Eric Raymond has written an article for the Linux Journal on how to build an Ultimate Linux Box. You can find the whole thing at http://www2.linuxjournal.com/cgi-bin/frames.pl/articles/style/0014.html The machine is said to compile the Linux 2.4.9 kernel in 1 min. 50 sec. I wonder how long it might take to build R on this beast... Cheers, Andy >

I used "/usr/bin/time" to time how long it took to join a DC to our domain. It took 9 hours, 54 minutes and 16 seconds. The logs follow: Committing SAM database Sending DsReplicateUpdateRefs for all the replicated partitions Setting isSynchronized and dsServiceName Setting up secrets database Joined domain DIGIPEN.EDU (SID S-1-5-21-REDACTED) as a DC 35461.84user 26.13system

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

i found two article said that rsync -a --delete empty/ a1/ will much more faster than rm when deleting millions files: http://linuxnote.net/jianingy/en/linux/a-fast-way-to-remove-huge-number-of-files.html http://www.quora.com/File-Systems/How-can-someone-rapidly-delete-400-000-files but my test gets opposite result, and i think it's impossible on theory. i use the command 'for i in

On Mon, Sep 26, 2016 at 8:08 AM, Carsten Mattner <carstenmattner at gmail.com> wrote: > On Mon, Sep 26, 2016 at 4:25 PM, Teresa Johnson <tejohnson at google.com> > wrote: > > No worries, thanks for the update. Teresa > > 2048 wasn't enough. Bumped to 4096. Only 1300 ninja targets left. > > Once I've been successful with this, I might try building a

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

Regarding the presentation I gave at the kvm forum on pagefaults. Two points: 1. pagefaults are important not just for migration. They are important for performance features such as autonuma and huge pages, since this relies on moving pages around. Migration can maybe be solved by switch to software but this is not a good solution for numa and thp since at a given time some page is likely