This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Summary: | LowPerformance took 54168 ms. | ||
---|---|---|---|
Product: | javaee | Reporter: | dwuysan <dwuysan> |
Component: | JSP | Assignee: | Marek Fukala <mfukala> |
Status: | NEW --- | ||
Severity: | normal | CC: | davideconsonni, dianiopiari, exceptions_reporter, hermenegildo, mtbadi39, tameren |
Priority: | P3 | Keywords: | PERFORMANCE |
Version: | 7.1 | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | DEFECT | Exception Reporter: | 186688 |
Attachments: |
nps snapshot
nps snapshot |
Description
dwuysan
2012-04-05 01:56:53 UTC
Created attachment 117850 [details]
nps snapshot
Created attachment 140161 [details]
nps snapshot
opening a jsp
*** Bug 209811 has been marked as a duplicate of this bug. *** JspDataObject.getFileEncoding() can be really slow. Since 2005, there's an optimisation (o.n.m.web.jspparser.FastOpenInfoParser) which quickly determines the JSP file encoding without running the 'true' jsp parser. However under some circumstances this parser can't properly provide the encoding and then it fallbacks to the jsp parser. This however means the thread is blocked until the jsp parsing thread finishes its work, which may take very long time. Even in the case when the true jsp parser is used to obtain the file encoding, the call doesn't need to necessarily be very slow. In most cases, just the first jsp parser call is slow, subsequent calls are not that bad. I'm not sure if it is worth of the effort to address this problem so I won't attempt to fix it now, but keep it open so we can track it. |