public inbox for goredo-devel@lists.cypherpunks.ru
Atom feed
From: Sergey Matveev <stargrave@stargrave•org>
To: goredo-devel@lists.cypherpunks.ru
Subject: Re: Slowness (caching issues?) in dependency checking
Date: Mon, 29 Aug 2022 21:25:33 +0300	[thread overview]
Message-ID: <Yw0Eq5+UeD3Wh+lS@stargrave.org> (raw)
In-Reply-To: <f4cf64d0-4b50-7647-089e-6a6e1fa27113@jnboehm.com>

[-- Attachment #1: Type: text/plain, Size: 1334 bytes --]

*** Niklas Böhm [2022-08-28 20:30]:
>That makes sense, then I guess this could be further decreased by setting
>REDO_NO_SYNC=1, although that was just something I noticed and am not
>bothered by.

Nothing is written during OOD-check, so NO_SYNC won't help in that case.
But during the build, when .redo/*.rec are created -- it will affect
filesystem operations.

>Thank you, that resolves my issue and helps by a lot.

Great, glad to hear about that hugely reduced time! There were huge
amount of syscalls, that are relatively slow especially because of
network filesystem delays.

>I agree that this is probably the explanation of the remaining difference,
>but that is an acceptable trade-off since the difference is not that large
>anymore.

I think it is acceptable tradeoff now too. Maybe there will be another
simpler format, but its worktime will be anyway negligible on NFS.

>By using separate files goredo plays much nicer with distributed
>systems; the sqlite database gets corrupted when more than one computer
>accesses it via a networked FS.

Somewhere apenwarr wrote that he also thinks his decision of single
database was wrong and database-per-directory should be preferrable.

-- 
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: 12AD 3268 9C66 0D42 6967  FD75 CB82 0563 2107 AD8A

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

      reply	other threads:[~2022-08-29 18:25 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-25 16:05 Slowness (caching issues?) in dependency checking Jan Niklas Böhm
2022-08-26 16:09 ` Sergey Matveev
2022-08-27  9:11   ` Jan Niklas Böhm
2022-08-28 14:49     ` Sergey Matveev
2022-08-28 18:30       ` Niklas Böhm
2022-08-29 18:25         ` Sergey Matveev [this message]