[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [Dltk-dev] SourceParserUtil cache miss

I remember we discussed it and I wasn't sure it should be fixed this way.

On Wed, Apr 18, 2012 at 21:04, Jae Gangemi <jgangemi@xxxxxxxxx> wrote:
>
> Â is there a reason you haven't pushed the patch upstream?
>
> Â i'd prefer not to be in the business of rolling my own core plugin sets,
> at least not yet, i've got enough on my plate w/ this thing as it is. :)
>
>
> On Mon, Apr 16, 2012 at 10:24 AM, Johan Compagner <jcompagner@xxxxxxxxx>
> wrote:
>>
>> local, i have some patches to the dltk and we ship our own plugins that we
>> build our self.
>>
>>
>>
>> On Mon, Apr 16, 2012 at 16:23, Jae Gangemi <jgangemi@xxxxxxxxx> wrote:
>>>
>>>
>>> Â do you have this patched in a sub-class or are you just using a local
>>> patched version of the core?
>>>
>>> Â i'm just trying to figure out where i'd drop this in (although it does
>>> seem like it's just a potential bug in general).
>>>
>>>
>>> On Mon, Apr 16, 2012 at 10:18 AM, Johan Compagner <jcompagner@xxxxxxxxx>
>>> wrote:
>>>>
>>>> Not sure if this is related but this is my patch that i have in
>>>> SourceModule
>>>>
>>>> ÂÂÂ public void makeConsistent(IProgressMonitor monitor) throws
>>>> ModelException {
>>>> ÂÂÂ ÂÂÂ // if (isConsistent())
>>>> ÂÂÂ ÂÂÂ // return;
>>>> ÂÂÂ ÂÂÂ // makeConsistent(false/*don't create AST*/, 0, monitor);
>>>>
>>>> ÂÂÂ ÂÂÂ HashSet<Openable> elementsOutOfSynchWithBuffers = ModelManager
>>>> ÂÂÂ ÂÂÂ ÂÂÂ ÂÂÂ .getModelManager().getElementsOutOfSynchWithBuffers();
>>>> ÂÂÂ ÂÂÂ synchronized (elementsOutOfSynchWithBuffers) {
>>>> ÂÂÂ ÂÂÂ ÂÂÂ if (!elementsOutOfSynchWithBuffers.contains(this))
>>>> ÂÂÂ ÂÂÂ ÂÂÂ ÂÂÂ return;
>>>> ÂÂÂ ÂÂÂ ÂÂÂ elementsOutOfSynchWithBuffers.remove(this);
>>>> ÂÂÂ ÂÂÂ }
>>>>
>>>> ÂÂÂ ÂÂÂ openWhenClosed(createElementInfo(), monitor);
>>>> ÂÂÂ }
>>>>
>>>> the above method is what i use, because i also did see double parsing
>>>> and so on.
>>>>
>>>> And we also use very large files so it was noticeable..
>>>>
>>>>
>>>> On Sun, Apr 15, 2012 at 22:22, Jae Gangemi <jgangemi@xxxxxxxxx> wrote:
>>>>>
>>>>> hello all -
>>>>>
>>>>> Â i'm noticing some kind of ISourceModuleInfo cache miss occuring in
>>>>> the SourceParserUtil.
>>>>>
>>>>> Â when i double click on a document to open in the editor, the
>>>>> ISourceModuleInfo is requested (line 48 of SourceParserUtil) is NOT the same
>>>>> object that is returned when SourceParserUtil gets invoked by the folding
>>>>> structure code, but it is the same object when the Reconcile thread fires
>>>>> next.
>>>>>
>>>>> Â the double parse is causing some slow downs on more complex objects.
>>>>>
>>>>> Â i've tried stepping through the code numerous times trying to track
>>>>> down the issue, but i haven't been able to figure out why the objects aren't
>>>>> the same. hopefully someone on the list can help. :)
>>>>>
>>>>> --
>>>>> -jae
>>>>>
>>>>> _______________________________________________
>>>>> dltk-dev mailing list
>>>>> dltk-dev@xxxxxxxxxxx
>>>>> https://dev.eclipse.org/mailman/listinfo/dltk-dev
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> dltk-dev mailing list
>>>> dltk-dev@xxxxxxxxxxx
>>>> https://dev.eclipse.org/mailman/listinfo/dltk-dev
>>>>
>>>
>>>
>>>
>>> --
>>> -jae
>>>
>>> _______________________________________________
>>> dltk-dev mailing list
>>> dltk-dev@xxxxxxxxxxx
>>> https://dev.eclipse.org/mailman/listinfo/dltk-dev
>>>
>>
>>
>> _______________________________________________
>> dltk-dev mailing list
>> dltk-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/dltk-dev
>>
>
>
>
> --
> -jae
>
> _______________________________________________
> dltk-dev mailing list
> dltk-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/dltk-dev
>