Cache DocBlocks #608
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,72 @@ | ||
| <?php | ||
| declare(strict_types=1); | ||
|
|
||
| namespace LanguageServer; | ||
|
|
||
| use Microsoft\PhpParser\Node; | ||
| use phpDocumentor\Reflection\DocBlock; | ||
| use phpDocumentor\Reflection\DocBlockFactory; | ||
| use phpDocumentor\Reflection\Types; | ||
|
|
||
| /** | ||
| * Caches DocBlocks by node start position and file URI. | ||
| */ | ||
| class CachingDocBlockFactory | ||
| { | ||
| /** | ||
| * Maps file + node start positions to DocBlocks. | ||
| */ | ||
| private $cache = []; | ||
|
There was a problem hiding this comment. please add an |
||
|
|
||
| /** | ||
| * @var DocBlockFactory | ||
| */ | ||
| private $docBlockFactory; | ||
|
|
||
|
|
||
| public function __construct() | ||
| { | ||
| $this->docBlockFactory = DocBlockFactory::createInstance(); | ||
| } | ||
|
|
||
| /** | ||
| * @return DocBlock|null | ||
| */ | ||
| public function getDocBlock(Node $node) | ||
| { | ||
| $cacheKey = $node->getStart() . ':' . $node->getUri(); | ||
| if (array_key_exists($cacheKey, $this->cache)) { | ||
|
There was a problem hiding this comment. It seems this is a rather hot path, so using There was a problem hiding this comment. Interesting - I could try how that affects the performance, but I'm not too optimistic. I think that forming the cache key dominates the performance impact of the function. There was a problem hiding this comment. Is there a reason why only There was a problem hiding this comment. It has try {
// create() throws when it thinks the doc comment has invalid fields.
// For example, a @see tag that is followed by something that doesn't look like a valid fqsen will throw.
return $this->docBlockFactory->create($text, $context);
} catch (\InvalidArgumentException $e) {
return null;
}There was a problem hiding this comment. Maybe we could use a NullObject instead of null in this cases? There was a problem hiding this comment. I'm not familiar with the There was a problem hiding this comment. A NullObject would only use unneeded memory and put pressure on the GC. There was a problem hiding this comment. Not with class NullObject {
public static function getInstance(): self {
static $instance;
return $instance ?? ($instance = new self);
}
}However, I'm still not convinced this would make the code clearer, especially since nullness only needs to be checked in one place. |
||
| return $this->cache[$cacheKey]; | ||
| } | ||
| $text = $node->getDocCommentText(); | ||
| return $this->cache[$cacheKey] = $text === null ? null : $this->createDocBlockFromNodeAndText($node, $text); | ||
|
There was a problem hiding this comment. This is hard to read, could you set parenthesis? |
||
| } | ||
|
|
||
| public function clearCache() | ||
| { | ||
| $this->cache = []; | ||
| } | ||
|
|
||
| /** | ||
| * @return DocBlock|null | ||
| */ | ||
| private function createDocBlockFromNodeAndText(Node $node, string $text) | ||
| { | ||
| list($namespaceImportTable,,) = $node->getImportTablesForCurrentScope(); | ||
| $namespaceImportTable = array_map('strval', $namespaceImportTable); | ||
| $namespaceDefinition = $node->getNamespaceDefinition(); | ||
| if ($namespaceDefinition !== null && $namespaceDefinition->name !== null) { | ||
| $namespaceName = (string)$namespaceDefinition->name->getNamespacedName(); | ||
| } else { | ||
| $namespaceName = 'global'; | ||
| } | ||
| $context = new Types\Context($namespaceName, $namespaceImportTable); | ||
| try { | ||
| // create() throws when it thinks the doc comment has invalid fields. | ||
| // For example, a @see tag that is followed by something that doesn't look like a valid fqsen will throw. | ||
| return $this->docBlockFactory->create($text, $context); | ||
| } catch (\InvalidArgumentException $e) { | ||
| return null; | ||
| } | ||
| } | ||
| } | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -141,6 +141,10 @@ public function __construct(ProtocolReader $reader, ProtocolWriter $writer) | |
| $e | ||
| ); | ||
| } | ||
|
|
||
| // When a request is processed, clear the caches of definition resolver as not to leak memory. | ||
| $this->definitionResolver->clearCache(); | ||
|
There was a problem hiding this comment. I don't understand why the cache needs to be cleared after every single protocol message. This is a very hot code path that is even hit in the middle of indexing. Could you explain? There was a problem hiding this comment. My intent was to
You're right, the code does not fulfill that intent. I also did not realize that it could be hit in the middle of indexing - I imagine that this might cause some weird behavior if user edit is performed on a file that is being parsed. There was a problem hiding this comment. It shouldn't happen while a file is parsing, but whenever control is yielded back to the event loop (definitely between indexing files) or getting file contents. The problem I have is that a cache is not useful if it is constantly cleared when it doesn't have to. For example, moving the mouse over a document can trigger thousands of hover requests within milliseconds. All of these would cause the whole cache to be cleared every time. There was a problem hiding this comment. Yeah - it currently only speeds things up when the same docblock is parsed multiple times on the same request. If it's moved into There was a problem hiding this comment. @felixfbecker - I started to move this to Should I
There was a problem hiding this comment. I see. Maybe create a dedicated class for getting docblocks that caches them? The only constraint is that the memory needs to be disposed when a PhpDocument is disposed. |
||
|
|
||
| // Only send a Response for a Request | ||
| // Notifications do not send Responses | ||
| if (AdvancedJsonRpc\Request::isRequest($msg->body)) { | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In the pre-tolerant parser version I used to save the docblock instance on the Node itself so they would get naturally get cached and garbage collected when the document gets garbage collected. The
CachingDocBlockFactoryinstance is saved in the DefinitionResolver, which is a long-living singleton-like object. Why not save this map onPhpDocumentinstances? That way it is not a cache that needs to be cleared on seemingly unrelated events like new messages, it is simply a memoization store to remember lazily computed docblocks. It might actually be just as fast to eagerly compute them all because we need to do that anyway to get the hover contents for the index.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This makes a lot of sense. Perhaps the name resolution cache from the Scope thing could also live in
PhpDocumentthen?