topcontexts

[Milian Wolff]

On Montag, 9. April 2018 19:42:26 CEST René J.V. Bertin wrote:
> On Monday April 09 2018 17:48:46 Milian Wolff wrote:
> >I quite frankly don't care. Sounds like HFS is a broken file system then.
> 
> Translation: "I don't care about Mac" ...? Somehow that doesn't surprise me.
> But it's good to know, I won't bother any longer to upstream Mac-specific
> improvements.
> 
> HFS is old and has its issues. I'm pretty certain APFS will have its own
> share of issues, just like about any other filesystem out there.
> >Then don't compress them. You wouldn't compress a folder with compressed
> >binary data either, like images, videos, music, ... or do you?
> 
> If I can get an additional 70% compression doing that, then yes I would.
> 
> >Well, you use KDevelop in a completely unsupported manner: You don't want
> >to cache anything. And you seem to suffer from HFS issues with compression
> >which we all don't use.
> 
> Oh, please read me correctly, and instruct yourself before making uninformed
> remarks. - I do not NOT want to cache anything. I don't mind regenerating
> it (because it makes an already slow operation only a bit slower) - I do
> not suffer from HFS compression. Again, I don't compress topcontexts and
> the operations I mentioned that took a lot of time have nothing to do with
> compression. Also, HFS only supports transparent DEcompression which comes
> at a neglible cost; ZERO cost for everything except reading the file
> contents.

Then I indeed have no clue what you are doing or why you want to remove the 
files. If as you claim there is no cost involved, then why do you try to 
optimize the number of files?

Maybe just write another of your patches that cannot be accepted upstream that 
essentially removes the writing of these files, if you don't want them. Sounds 
like that is way less work...

> >Yes, one per encountered file.
> 
> Including system headers? That would explain why a session with 2 really
> small projects reaches 1040 topcontext files.

Yes.

> >LMDB is afaik unsafe to use on NFS.
> >Was this fixed?
> 
> Running a duchain cache dir on NFS must be ... interesting...
> Baloo uses LMDB so if baloo works on NFS home dirs any issues LMDB might
> have had with that must have been fixed.

It definitely is, but we have to cope with it.

> >And does it work on
> >Windows nowadays?
> 
> I've seen mention of a fix or two targetting MS Windows but that's an issue
> for later AFAIC. I've picked LMDB because it claims to do memory mapping,
> but that may actually be overkill if KDevelop already does its own
> mmapping. Maybe leveldb will be sufficient - and that one is bound to work
> on MS Windows. For now I've only focussed on creating the database and
> apparently this is done only when projects are unloaded.

No, that's not true. It's created whenever we write to disk, which happens 
intermittedly too, cf. the duchain cleanup thread.

> BTW, is there a reason why the different files (keys) aren't written in
> order sorted by topcontext index? Maybe they will rarely if ever be read in
> a known order from storage?

Yes.

-- 
Milian Wolff
mail at milianw.de
http://milianw.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20180409/64c57f44/attachment.sig>