kadircet wrote: > We could cut the memory usage overhead of the patch in half by only having it > in one of them. (@kadircet would that change your analysis of the tradeoffs > at all?)
I think that'd still be too much considering the functionality we'll get in the end. Others might not share my values here, but my guiding principle has been: We shouldn't increase costs of overall clangd infrastructure, if it isn't going to benefit ~all users and functionality. https://github.com/llvm/llvm-project/pull/127359 is a good example of this. That patch cost us some memory (1%), but in return we got improvements on workflows that are ~always used, and available in pretty much all the editors (signature help & diagnostics). The justification I have for eating costs in such features is, even if we handled them in a narrower focus, we'd still pay those costs ~always (since they're going to be used frequently by all users). Hence if the feature is worth implementing, resource costs are fine to move into core bits of clangd (it would usually result in better complexity/resource usage overall). > A more general musing: it would be nice to have a mechanism for storing > additional information for a subset of symbols, without incurring the > overhead of increasing the representation size of every symbol. As a result of that principle, I am definitely in favor of such mechanisms, bearing maintenance/feature trade-offs in mind. (For example `ClangdModules` was an action we were trying to take in this direction. It actually aims to provide people infrastructure to implement their desired functionality in clangd, while limiting resource and maintenance costs to only that specific feature and its users. but then we took an arrow in the knee) https://github.com/llvm/llvm-project/pull/118102 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
