Bug 230544 - GsfCodeTemplateProcessor blocks EDT
GsfCodeTemplateProcessor blocks EDT
Status: RESOLVED FIXED
Product: editor
Classification: Unclassified
Component: Completion & Templates
7.4
All All
: P3 (vote)
: 8.1
Assigned To: Dusan Balek
issues@editor
EXCEPTIONS_REPORT perf-profileme
: PERFORMANCE
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-05-30 17:07 UTC by jan.kurnatowski
Modified: 2015-03-02 09:47 UTC (History)
15 users (show)

See Also:
Issue Type: DEFECT
:


Attachments
nps snapshot (40.68 KB, application/nps)
2013-05-30 17:07 UTC, jan.kurnatowski
Details
nps snapshot (672.23 KB, application/nps)
2013-06-07 11:01 UTC, s.ryabov
Details
nps snapshot (31.33 KB, application/nps)
2013-06-10 09:19 UTC, maulnick
Details

Note You need to log in before you can comment on or make changes to this bug.
Description jan.kurnatowski 2013-05-30 17:07:36 UTC
This bug was originally marked as duplicate of bug 225603, that is already resolved. This bug is still valid, so this seems to be another bug, but it might be related.

Build: NetBeans IDE Dev (Build 201305292301)
VM: Java HotSpot(TM) 64-Bit Server VM, 23.21-b01, Java(TM) SE Runtime Environment, 1.7.0_21-b11
OS: Windows 7

User Comments:
jan.kurnatowski: I was editing a PHP file using Ctrl+C, Ctrl+V, Ctrl+Z



Maximum slowness yet reported was 4259 ms, average is 4259
Comment 1 jan.kurnatowski 2013-05-30 17:07:38 UTC
Created attachment 135155 [details]
nps snapshot
Comment 2 Tomas Zezula 2013-05-31 13:48:49 UTC
Calling PM.parseWSF from EDT.
Comment 3 Svata Dedic 2013-06-04 10:39:09 UTC
CSL performs parsing in its CodeTemplateProcessor in order to get proper data for updating template values. 

1/ The editor parsing loop blocks on behalf of PHP SemanticHighlighter doing some post-processing of Parser.Result, so one of options is to break 'the long part' of the post-processing out from the parser task so that parser will not be blocked. 

2/ Although the code template must be inserted in AWT thread into the component, the updateValues could be possibly split to a request processor so the preparation can take an extended time. This would however change the threading model for existing CodeTemplateProcessor implementations - the threading model is not specified IMHO, but at least Java and PHP access JTextComponent from their updateDefaultValues. The change must not be transparent, but an extended interface for (potentially) long-running processors could be crated.

It's not permitted to leak Parser.Result out of the parsing task. CSL could in theory run parsing in a RP in its GsfCompletionItem.defaultSubstituteText, call the CodeCompletionHandler.resolveTemplateVariable in advance outside EDT, save the results and pass them 'around' into the invoked CodeTemplate.insert() running in EDT. I can prototype it; it seems as rather fragile solution, but could fix this particular case.
I am still not 100% about threading model of the CodeTemplate APIs - Milo, please advise.

Still I would opt to both the above additional changes: It's not good to block parsing for such a long time as PHP semantic highlighter does (1), and it would be great to have a systematic support for sophisticated template processors (2)

Opinions ?
Comment 4 s.ryabov 2013-06-07 11:01:37 UTC
Created attachment 135495 [details]
nps snapshot

autocomplete in php code
Comment 5 maulnick 2013-06-10 09:19:30 UTC
Created attachment 135574 [details]
nps snapshot

long response time
Comment 6 Ondrej Brejla 2013-08-21 07:47:58 UTC
That problem with long running semantic highlighter in PHP has been fixed already in dev build.
Comment 7 Dusan Balek 2015-03-02 09:47:59 UTC
No occurence since 7.3.1. Closing as fixed.


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo