| Horrendous performance 0.7.1 - will it get better [message #143621] |
Fri, 14 October 2005 09:47  |
Eclipse User |
|
|
|
Prior to the release of WTP 0.7, we were using the Sysdeo Tomcat plug-in
for our Spring framework project.
We decided to move to WTP, thinking that the XML and JSP validation
would be a bonus.
Instead, what we have is:
- Constantly having to clean the project, as it gets into a state where
it can't do the basics of compiling the src dir, somehow failing to be
able to resolve classes within the same project.
- Finding that some directories aren't copied to .deployables when doing
a build, but getting no warnings why, just empty dirs. The only
solution, a full clean.
- It taking ages to do a build, much of the time seeming to get stuck on
XML validation.
What is worring me is that this may be the accepted performance.
Does anyone on the team acknowledge any "order of magnitude" issues with
performance, or is this roughly what we can expect?
Sorry if this comes across as a bit of a rant. I love where this is
going, but I'm concerned that I'll be needing a much faster machine than
my usually blistering Compaq Evo 2000+ laptop.
Cheers,
Neale
|
|
|
| Re: Horrendous performance 0.7.1 - will it get better (0.7.2 soon?) [message #143921 is a reply to message #143621] |
Fri, 14 October 2005 17:41  |
| Eclipse User |
|
|
|
Neale wrote:
> Instead, what we have is:
> - Constantly having to clean the project, as it gets into a state where
> it can't do the basics of compiling the src dir, somehow failing to be
> able to resolve classes within the same project.
> - Finding that some directories aren't copied to .deployables when doing
> a build, but getting no warnings why, just empty dirs. The only
> solution, a full clean.
> - It taking ages to do a build, much of the time seeming to get stuck on
> XML validation.
I am experiencing each of these three problems, too (haven't yet tried
0.7.1 though).
Plus, one of the most annoying problems is with editing large XML files,
if you've got only one syntax error (non-well-formed document), editing
takes several seconds for each keypress, because the validator is busy
drawing red underlines and clearing them. It can take minutes to clean
up such errors.
I hope there will be a 0.7.2 in the next few weeks that will fix these
problems.
Regards,
Andreas
|
|
|
|
| Re: Horrendous performance 0.7.1 - will it get better (0.7.2 soon?) [message #143973 is a reply to message #143921] |
Sat, 15 October 2005 01:36 |
| Eclipse User |
|
|
|
Andreas Schildbach wrote:
> Plus, one of the most annoying problems is with editing large XML files,
> if you've got only one syntax error (non-well-formed document), editing
> takes several seconds for each keypress, because the validator is busy
> drawing red underlines and clearing them. It can take minutes to clean
> up such errors.
So this may be easy to work around. Simply turn of the 'as you type
validation' option in the Structured Source Editor preferences. I'd be
curious to know how large your XML files are. Even better, can you open a
bug for this problem and attach a sample file. One approach we've
considered is to impose an upper bound on the size of the XML file that
we'll attempt to 'red squiggle'. We're probably being a bit too
aggressive with the frequency we revalidate large files. Making the time
delay between validations propertional to the document size may help a lot
here too. Feel free to open a bug to request that our 'as you type
validation' takes file size into validation.
Having said all that, for really large files validation may not really be
the culprit here at all. There's some computation time req'd to keep the
underlying SSE DOM model in sync with your text changes. Please let us
know how things behave with the 'as you type validation' turned off... if
performance still stinks then chances are it's our DOM synchronization
code.
At a certain point we expect that huge XML files really degrade the
performance of the XML editor. Though we're doing some good work to
improve this, realistically there'll always be a memory limit at which our
editor will start to crawl. Our goal is to push this limit high enough
that it only a largest multi megabyte XML files will cause problems.
So thanks for the feedback. And please give those work arounds a try and
post back with your findings. Open bugs and attach sample files too!
thanks
craig
|
|
|
Powered by
FUDForum. Page generated in 0.02714 seconds
Home