Sluggish behaviour in WeBuilder

[davenz]

I am trying to replicate a possible bug which affects both machines that I have installed WB on.

I am using the latest build (available by using the 'check for updates feature within WB) on Vista business. I have the 'full' layout selected with Word Wrap, Highlight URL's, Show Hidden Characters and Auto Spell Check enabled.

To replicate my issue:

Open a new blank page. Insert a single p opening and closing tag between the body tags.

Paste approximately 1000 words (around 1 and a half A4/Letter pages of standard-sized text) into the P tag and monitor WB performance as you try to type in anything else after that. Do you experience any delays or sluggish behaviour, like the software 'stalling' for a few seconds before the text 'catches up' to your typing? Try adding another 500 words or so; 1000 words in one tag appears to be the 'cut-off' point for my machine before WB slows down noticibly and produces this behaviour.

Pasting 2000 words into the single tag renders WB unusable and almost totally unresponsive on my main machine, which is no slug.

Interestingly, if I split the text up into seperate blocks using 'P' tags, the problem disappears altogether.

For those wondering why, I often use single tags to wrap long bodies of text for CSS reasons, using line breaks to format it instead of tags. All my other editors (that I don't use any more) handle this condition happily.

Can anyone else confirm this behaviour please?

Cheers

Dave.

[chrisjlocke]

Do you also have a 'Preview' tab visible? (eg, Horizontal split, Vertical split, etc)

I've pasted "Mary has a little lamb" (several times - 24,000+ characters) and it exhibits this behaviour on my WinXP machine.
WeBuild.exe is using high CPU cycles at this point.

[davenz]

It makes no difference if I have the preview open or closed; the sluggish behaviour is present either way. If I pasted in 24,000 words I doubt if WB would even respond on my machine. I would expect any editor to be struggling with that many words! When I tried 4000 I had to exit WB using the task manager.

Thanks for your feedback.

Dave.

[chrisjlocke]

I would expect any editor to be struggling with that many words!

Nah - 24,000 words (assume 7 characters per word) is only 164KB - nothing to it. Ooh, forgot the spaces. 192KB. Even Notepad can handle several MB of text quite happily.

I suspect its down to the highlighting of the code, or WeBuilder trying to find closing tags within the long string, etc.

[MikeyB]

No problem what so ever here.

Just pasted 25,839 words (146,718 characters) into a single <p> tag and my CPU usage is sat there at 0%.
WeBuilder is using 50,372K of memory

If I start typing WeBuilders CPU usage goes up to 5% till it starts scrolling the window across then it went up to 14%

I tries pasting as one big block, or as individual lines, and no difference, WeBuilder didn't slow at all.

[chrisjlocke]

MikeyB - Have you autocomplete on?
Davenz- What about you? If I turn off this feature, the delay goes.



(My autocomplete list was initially empty, so I added a dummy entry to see if that helped. It didn't.)

[davenz]

Hi there.

No, turning off those features did not change the behaviour.

For testing I made a page as above with 3000 words in it. Typing at the beginning of the tag, while slower than 'normal' text entry, is way faster than typing something at the end of the tag, where it takes a full 5 seconds for the text to appear after typing, even though the cursor itself moves along the page; the text isn't rendered until that delay expires. Weird. At this point WB is using 50% of my CPU, until the text is displayed, whereby CPU usage goes back to 0.

As an aside, last night I opened a newsletter in WB that I created in another editor in order to edit it. With preview on, horizontal or vertical, replacing text in it (I use the old page as a template and just overwrite the text to update it) becomes a real chore, with every third or fourth letter typed not entered, thusget tet likthis enterd. Unusable for me with the preview on. I imagine it is related to this same bug. Complex pages seem to bog it right down. My machine is an AMD X2 64 5200, 4 gigs of RAM, 10,000 RPM Raptor system drive, 500g slave drive and a Nvidia based 8800GT video card; not a monster machine but by no means a slouch either. No other applications gag this machine like WB, so it would be interesting to know why it is doing it. I would be surprised if it was a lack of grunt that was causing the problem. I have used four other html editors over the years, and still have them installed; none exhibit this behaviour, (though MS Expression Web 2 is sluggish on my machine it is nowhere as bad as WB with this text input issue).

not intending to advertise, the newsletter can be found here if you want to try editing it to see if you can replicate the issue:

http://www.pcanytime.co.nz/newsletter.html

sorry for the link. Moderator, please delete it if you feel it is inappropriate.

I have tried turning off all auto-this or that type options, and a few others related to the display, but nothing makes any perceptible difference.

Cheers

Dave.

[MikeyB]

Chris, yes I have both auto complete and auto replace turned on, here's my list in auto replace:


Dave,
I downloaded that newsletter file, but get no slow down at all, even when editing with preview open.
Because you have the full url for the images, every time you make a change and the preview is refreshed it will go off to the server and get the image files again, could this be slowing you down?

But for me even when the preview is refreshing typing does not slow down at all, even mid-refresh.

[davenz]

Hi Mikey

it is local when I am editing it - I edit it all locally and upload it to the server once done.

The whole thing is strange; WB is the only software I have this trouble with. It must be something peculiar to my machine and setup. Just my luck ...

I will try and record a screen movie of it

Thanks for your time.

Dave.

[chrisjlocke]

No problems with that newsletter. I don't think its entirely your machine, as I can at least replicate the slowdown with large amount of text in a single P tag.
I was hoping the 'Auto Complete' would be helpful for you. Shame it wasnt.

[davenz]

Hi Chris

Yes, sorry, I forgot you did replicate part of the issue.

I have tried every possible setting on/off to try and figure out why this happens, not only to make it work for me the way I want to code but for the devs who might have been able to do something about it.

I have not noticed the newsletter issue previous to last night so it isn't a biggy, just something I noticed that might be a clue to the mystery.

It isn't a deal breaker for me anyway, just a minor annoyance, especially when it only happens to a few machines out of thousands.

Have a good one..

(Edit)
I just thought of something relevant; I have preview refresh set to 1 second and 'create file backups on save'. A problem I also have regularly is that the preview file can't be found. I see it mentioned here occasionally, and I'm not bothered by it, but it is interesting that this happens. If I let it go, I get a dialog box every second pop up to tell me the page cant be found, until I click them all away and WB settles down again. Seems a weird way of doing it to me...

Dave.

[chrisjlocke]

Yes, the 'file not found' is a common one unfortunately, but is linked to the way the preview window works (or doesn't! )

My 'Create backups on save' is off. Have you tried increasing the refresh value to see if that helps? 1 second seems rather frequent.

[MikeyB]

Hi,

I think I've just come across something similar.

I did a "view source" on an ASP generated page (not my script!) and WeBuilder virtually died on me.
The page is quite big, the generated HTML is 190KB, the problem being that 187KB of it are on one line.
WeBuilder doesn't like this very long (192,264 characters) line.

Trying to type CPU usage of WeBuilder goes to 50%.
The further along the line the slower things get.
At the end of the line typing or just moving the cursor takes more than a minute for WeBuilder to respond to each keypress.
While else where in the document it's probably about 0.25 second response between keypresses.

I don't have Word Wrap on, never do!

Just did a test with Word Wrap on, and WeBuilder "draws" the line very slowly, kind of like the old football results on the telly

[Gatis]

Yes, there are problems if you have very long lines inside your code.
We have not found a solution for this yet. But it is also true, that code like that is not very common, is it?

[davenz]

Well, I am not a professional coder like you guys, but for example I am getting ready to publish one of my novels on my web site. Previously, I was just writing the entire book text inside one P tag per page/chapter and using line breaks to format it. If I do this with Webuilder, it gets to a point where my page is no longer editable as it gets so sluggish. I suppose I could use thousands of P tags to format it, but surely I shouldn't have the software dictate to me how I code my site because it breaks if I try it the way I am happiest with?

There must be something causing the high cpu usage in the rendering engine because, as I mentioned, none of the other editors (competitors of yours) exhibit this behaviour.

Dave.