<div dir="auto">We  have actually already implemented it in clangd: we store up to 3 last used ASTs and drop the rest at the moment.<div dir="auto"><br><div dir="auto">It's possible to make this configurable, if necessary.</div><div dir="auto"><br></div><div dir="auto">In general, I guess only one clangd instance will be actively processing requests (i.e. dealing with user Interactions) at any given time, while others will only be handling background tasks.</div><div dir="auto"><br></div><div dir="auto">It means we're should probably be fine resource-wise.</div><div dir="auto"><br></div><div dir="auto">Another thing about the xpc adapter is that it's Mac-only, right?</div><div dir="auto">Therefore, we can potentially break you without knowing about it. Even though that should be rare, given the design, what's our plan there? Having a buildbot running Mac? Relying on you and the other Mac users nagging us when it's broken?</div><div dir="auto"><br></div><div dir="auto"><br></div></div></div><br><div class="gmail_quote"><div dir="ltr">Jan Korous via clangd-dev <<a href="mailto:clangd-dev@lists.llvm.org">clangd-dev@lists.llvm.org</a>> schrieb am Di., 14. Aug. 2018, 14:37:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><br><div><blockquote type="cite"><div>On 13 Aug 2018, at 17:10, Ilya Biryukov <<a href="mailto:ibiryukov@google.com" target="_blank" rel="noreferrer">ibiryukov@google.com</a>> wrote:</div><br class="m_-4881889468549110848Apple-interchange-newline"><div><div dir="ltr" style="font-family:Helvetica;font-size:13px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">Thanks for the details.<div>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.</div><div>In that case, it does make sense to avoid losing time converting between the protocols.</div></div></div></blockquote><div><br></div><div>Right, the other motivation is that XPC is a prescribed form of IPC for client-service on macOS and actually provides more user-friendly API than POSIX. So we need to use it but there’s no specific requirement *how* to use it and actually this form of optimization is also used by some other services.</div><div>Anyway, we could consider this just an implementation detail and add a minimal JSON string -> xpc_dictionary conversion for LSP as a library for clangd XPC consumers to use. Then we could label the XPC representation as a stable API. Not sure if that’s necessary though. What do you think?</div><br><blockquote type="cite"><div><div dir="ltr" style="font-family:Helvetica;font-size:13px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div><br></div><div>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.</div></div></div></blockquote><div><br></div><div>We were also discussing that and our main concern were possibly duplicate ASTs in different clangd processes’ memory. Since our supported use-case is "just a few workspaces” (think 1-3 with let’s say 5 being already an extreme case) we concluded that for the time being it’s fine. In general we’d just use some reasonable limits for resources (e. g. -j 10 or whatever value we find optimal for worker threads). For general memory consumption we’ll need to implement some strategy anyway since in our case clangd would be a long-lived process running on developer’s machine. We were thinking about keeping N least recently used ASTs in memory and dropping the rest. </div><br><blockquote type="cite"><div><div dir="ltr" style="font-family:Helvetica;font-size:13px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div><br></div></div><br style="font-family:Helvetica;font-size:13px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div class="gmail_quote" style="font-family:Helvetica;font-size:13px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div dir="ltr">On Fri, Aug 10, 2018 at 7:01 PM Jan Korous <<a href="mailto:jkorous@apple.com" target="_blank" rel="noreferrer">jkorous@apple.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><div><blockquote type="cite"><div><br>On 9 Aug 2018, at 18:00, Ilya Biryukov <<a href="mailto:ibiryukov@google.com" target="_blank" rel="noreferrer">ibiryukov@google.com</a>> wrote:</div><br class="m_-4881889468549110848m_599287317744190033m_-7429177264232536160Apple-interchange-newline"><div><div dir="ltr">Hi Jan,<br><div><br></div><div>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.</div><div>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.<br></div><div>Am I reading it correctly?</div></div><br></div></blockquote><div><br></div><div>Hi Ilya,</div><div><br></div><div>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.</div><div>Since we might possibly need to use ranking and filtering logic on client side this use-case is interesting for us.</div><div><br></div><div>Cheers,</div><div><br></div><div>Jan</div><br><blockquote type="cite"><div><div class="gmail_quote"><div dir="ltr">On Wed, Aug 8, 2018 at 5:38 PM Jan Korous via clangd-dev <<a href="mailto:clangd-dev@lists.llvm.org" target="_blank" rel="noreferrer">clangd-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space">Hi all,<div><br></div><div>Based on our discussion with Sam in <a href="https://reviews.llvm.org/D48559" target="_blank" rel="noreferrer">https://reviews.llvm.org/D48559</a> we talked about our requirements internally and ultimately decided to change our approach.</div><div><br></div><div>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.</div><div><br></div><div>I put our current design for review to continue the discussion.</div><div><a href="https://reviews.llvm.org/D50452" target="_blank" rel="noreferrer">https://reviews.llvm.org/D50452</a></div><div><br></div><div>I would like to thank you all for the great feedback you gave us! It helped us to precisely pinpoint our requirements.</div><div><br></div><div>Thanks.</div><div><br></div><div>Jan</div><div></div></div>_______________________________________________<br>clangd-dev mailing list<br><a href="mailto:clangd-dev@lists.llvm.org" target="_blank" rel="noreferrer">clangd-dev@lists.llvm.org</a><br><a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/clangd-dev" rel="noreferrer noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/clangd-dev</a><br></blockquote></div><br clear="all"><div><br></div>--<span class="m_-4881889468549110848Apple-converted-space"> </span><br><div dir="ltr" class="m_-4881889468549110848m_599287317744190033m_-7429177264232536160gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>Regards,</div><div>Ilya Biryukov</div></div></div></div></div></div></blockquote></div><br></div></blockquote></div><br clear="all" style="font-family:Helvetica;font-size:13px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div style="font-family:Helvetica;font-size:13px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br></div><span style="font-family:Helvetica;font-size:13px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">--<span class="m_-4881889468549110848Apple-converted-space"> </span></span><br style="font-family:Helvetica;font-size:13px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div dir="ltr" class="m_-4881889468549110848m_599287317744190033gmail_signature" data-smartmail="gmail_signature" style="font-family:Helvetica;font-size:13px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div dir="ltr"><div><div dir="ltr"><div>Regards,</div><div>Ilya Biryukov</div></div></div></div></div></div></blockquote></div><br></div>_______________________________________________<br>
clangd-dev mailing list<br>
<a href="mailto:clangd-dev@lists.llvm.org" target="_blank" rel="noreferrer">clangd-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/clangd-dev" rel="noreferrer noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/clangd-dev</a><br>
</blockquote></div>