[clangd-dev] Clangd + XPC
Ilya Biryukov via clangd-dev
clangd-dev at lists.llvm.org
Mon Aug 13 09:10:35 PDT 2018
Thanks for the details.
The "json-inside-xpc" looks a bit hacky on first notice, but the adapter is
actually trying to solve a different problem of dispatching requests to the
correct clangd instance based on the workspace.
In that case, it does make sense to avoid losing time converting between
One thing that might turn out to be problematic with the
'clangd-per-workspace' approach is that clangd manages some resource (ASTs,
worker threads) and, obviously, can only do that inside a single process,
so there are possibilities of resource starvation if too many clangd
instances are running at the same time and don't know about each other.
On Fri, Aug 10, 2018 at 7:01 PM Jan Korous <jkorous at apple.com> wrote:
> On 9 Aug 2018, at 18:00, Ilya Biryukov <ibiryukov at google.com> wrote:
> Hi Jan,
> Thanks for the update! It's great that we're after a solution that works
> at the protocol boundary, that does sound like something that should be
> easier to maintain and not too complicated.
> I have skimmed through the patch, and as far as I can tell the idea is to
> forward raw JSON messages back and forth via XPC without actually
> converting from JSON to XPC and back.
> Am I reading it correctly?
> Hi Ilya,
> Yes that’s correct - we did some performance measurements and it turned
> out that for JSON containing a lot of sub-objects (think 40k
> CompletionItem) the cost of conversion to XPC dictionary is actually
> higher than what we gain at IPC. Just sending string over XPC is faster.
> Since we might possibly need to use ranking and filtering logic on client
> side this use-case is interesting for us.
> On Wed, Aug 8, 2018 at 5:38 PM Jan Korous via clangd-dev <
> clangd-dev at lists.llvm.org> wrote:
>> Hi all,
>> Based on our discussion with Sam in https://reviews.llvm.org/D48559 we
>> talked about our requirements internally and ultimately decided to change
>> our approach.
>> We are going to use serialized JSON LSP over XPC instead of custom
>> transport layer and we aren’t going to indroduce XPC-specific code to
>> clangd binary itself which has several advantages.
>> I put our current design for review to continue the discussion.
>> I would like to thank you all for the great feedback you gave us! It
>> helped us to precisely pinpoint our requirements.
>> clangd-dev mailing list
>> clangd-dev at lists.llvm.org
> Ilya Biryukov
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the clangd-dev