4 ms·

Interesting. Chromium seems to be huge indeed. I googled statistics: 3+ million lines of code? Is that about right? (Not that LOC is a great universal metric of

Interesting. Chromium seems to be huge indeed. I googled statistics: 3+ million lines of code? Is that about right? (Not that LOC is a great universal metric of everything, but it's something.) For comparison: I work on something a magnitude smaller: https://github.com/CleverRaven/Cataclysm-DDA/ https://github.com/CleverRaven/Cataclysm-DDA/ ... about ~360,000 LOC. CLion is pretty great for that. I'm curious, have the VM garbage collection and allocation settings been adjusted? In other words, not just the memory limits but also switching to a different garbage collector and the GC control mechanisms adjusted? I've been reading up on the collectors. As far as I can tell the G1 collector is strongly indicated when you go above a 4 or 8GB heap. It then has a number of settings to adjust. I got really good and smooth performance out of it - few and short enough pauses that I was at peace with CLion - but seemingly I set the garbage collection to be "too continuous" which caused constant CPU usage when I used that profile in Pycharm on a Python project. Had to switch Pycharm back to a more, uh, classical GC setup. (I didn't reconfigure to rein it back in as it was unnecessary in that context. I'm sure it's possible.) The JVM and the GC are a rather interesting beast. Just curious :)

cmrdporcupine 7y ago
Yes it's a massive project. I've attempted all sorts of GC tuning. I'm not convinced it's all GC issues; I think whatever data structures or algorithms they are using for their semantic tree must not scale well to extremely large data sets. It also doesn't seem to be terribly friendly to high concurrency. Having lots of cores doesn't really help. CLion seems to struggle in particular with the presence of the out / generated source directories in Chromium. Even when asked not to index (exclude), the mere presence of the directory seems to bog it down. The tool also needs to have a more flexible notion of source roots/include roots. I should be able to notify it that a directory is an #include root without having it try to index every .c file etc. underneath there. I should be able to select a group of directories and say "these have headers, but they're relative to path X, rather than themselves" etc.
- AnthonBerg 7y ago
  Many thanks! I assumed that GC tuning had indeed been attempted.
ensiferum 7y ago
Is this even including all the stuff that gets pulled in as a 3rd party dep? Some significant portions of the code live there such as angle, blink etc.

cmrdporcupine 7y ago

Yes it's a massive project. I've attempted all sorts of GC tuning. I'm not convinced it's all GC issues; I think whatever data structures or algorithms they are using for their semantic tree must not scale well to extremely large data sets. It also doesn't seem to be terribly friendly to high concurrency. Having lots of cores doesn't really help. CLion seems to struggle in particular with the presence of the out / generated source directories in Chromium. Even when asked not to index (exclude), the mere presence of the directory seems to bog it down. The tool also needs to have a more flexible notion of source roots/include roots. I should be able to notify it that a directory is an #include root without having it try to index every .c file etc. underneath there. I should be able to select a group of directories and say "these have headers, but they're relative to path X, rather than themselves" etc.

AnthonBerg 7y ago
Many thanks! I assumed that GC tuning had indeed been attempted.

ensiferum 7y ago

Is this even including all the stuff that gets pulled in as a 3rd party dep? Some significant portions of the code live there such as angle, blink etc.