Saving file slow under Windows 7?

[rgoudie]

Greetings!

This question is for other users who are working under Windows 7. Do you find that it takes up to 7 to 10 seconds to save a file when working with an HTML file in WeBuilder 2011 (11.1.0.128)?

Ever since I installed Windows 7 on my computer, every time that I press Ctrl-S or click the Save button, the system freezes consistently for between 7 and 10 seconds. With no other software does this occur. Not with TextPad, Excel, Word, Notepad, etc.

I did exchange a few e-mails with Tech Support, but the tendency was to inquire whether an anti-virus or such was interfering. I only have AVG installed as my anti-virus. I don't see why the act of writing data to a file should take so long. Perhaps the software is doing some validation before outputting the text to the file?

Having been left with an unsatisfactory answer from Tech Support, I had been evaluating another piece of similar software during the past few weeks. The evaluation is about to expire, but I still have hopes for WeBuilder, so that is why I am here. However, I cannot accept waiting for even 5 seconds each time that I press Ctrl-S. I do this often, so the delay is quite the showstopper for me.

So, I am asking to see if I am the only person experiencing this delay when using WeBuilder with Windows 7.

EDIT: This only becomes noticeable with large files. The file in question is 414 Kb. Also, the actual writing doesn't start until after the 7 to 10 seconds has elapsed. Then, once the process starts, it is immediate (as it should be). It would seem that the program is doing something before actually starting to write to the file.

Thank you for your replies.

-Ray.

[rstoekenbroek]

Ray,

I use a Win7 HP laptop. Created a 709kB, 14442 lines of PHP code, source file using ädvanced cut-and-paste...
Loaded in a split second. Responded OK to editing commands (select TAG block, etc.).
Also saved in a split second.

Complex commands, such as "Format PHP code" took two minutes to complete. But I can live with that!
So I assume there is something wrong on your machine.

Kind regards,

[rgoudie]

Thank you for your reply, Rob.

I still cannot understand why only WeBuilder seems to exhibit this symptom. The other piece of software that I was evaluating did not exhibit this problem. As mentioned, no other program takes more than a few milliseconds to save a document. Very curious indeed.

-Ray.

[reacher]

No such delay on any of my Windows 7 machines (using both 32 and 64bit Ultimate versions). Saving is instant with no other delays.

[rgoudie]

Thank you for your reply. Okay, well, I can accept that there is something in my configuration, but I don't know what else to do. I turned off my AVG anti-virus, yet the symptom persists.
I will be forced to go to another software.

Thank you for your time.

-Ray.

[Aivars]

Just out of curiosity you could use Process Monitor (http://technet.microsoft.com/en-us/sysi ... s/bb896645) i.e. its Filemon part that lets you see all file operations performed by computer to see what exactly is slowing saving down.

[rgoudie]

Thank you for the great reply. I did download and install Process Monitor. I set a filter for process name webuild.exe and cleared the log display.
I made a change in my HTML file and then clicked on the Save icon. In the Process Monitor display, I saw nothing for about 8 seconds, then a dump of the save operation appeared. This produced a large number of entries.

The result of this test demonstrates that the program is not starting the actual write operation until after a number of seconds has elapsed. I do not know what is going on internally. Is there some debug level that I can use to create a dump of the internal operations?

If you have any further suggestions, I would be happy to receive them.

-Ray.

[Aivars]

Try running it without the filter, see if anything else keeps doing something with the file during these 8 seconds. Although I'm not in Webuilder team, I suspect this isn't a case of Webuilder doing something (otherwise this problem would be more common) but a case of something blocking Webuilder's file operation to do something on its own.

[rgoudie]

Well, with no filters, the amount of output from all processes is overwhelming. I decided to use a filter on the path that includes the name of my HTML file. Here is what I discovered:

When I first click on the Save icon, the program attempts what Process Monitor calls a QueryDirectory operation. Then, 8 seconds later, the program launches into a CreateFile operation, followed by many subsequent operations.

So, it would now seem that the initial QueryDirectory operation is jamming.

-Ray.

[rgoudie]

I've even tried running WeBuilder in Windows XP (SP 3) compatibility mode and as administrator, but the save still takes time.

[MikeyB]

Well, with no filters, the amount of output from all processes is overwhelming. I decided to use a filter on the path that includes the name of my HTML file. Here is what I discovered:

When I first click on the Save icon, the program attempts what Process Monitor calls a QueryDirectory operation. Then, 8 seconds later, the program launches into a CreateFile operation, followed by many subsequent operations.

So, it would now seem that the initial QueryDirectory operation is jamming.

-Ray.

Hi,

How many files already exist in the directory where you are trying to save the file?
If there are many many files then it's a possibility that would slow it down.

[rgoudie]

Mikey, there are only 8 files in the directory as well as 4 sub-directories, which each contain an average amount of files.

Hi,

How many files already exist in the directory where you are trying to save the file?
If there are many many files then it's a possibility that would slow it down.

[reacher]

Query directory delays can possibly occur if either of the following are true:

you are connected to a network and have either connected or mapped drives or

you have an external drive or drives which may or may not be connected.

Windows explorer will always try to parse and/or reconcile network or removable drives' paths, which can cause sometimes long delays before opening or saving files (some programs utilise internal Windows mechanisms to check drives and paths exist (or not as the case may be) and some don't; WeBuilder may well do so I don't know). While this was more pronounced in older versions of Windows, the possibility still exists if machines have been or are connected to networks and/or removable drives. Without closer monitoring (Process Monitor is fine to use but output can be overwhelming if you have registry, files and process all enabled - try disabling them as required just to narrow the field a bit) it is impossible to say why your particular Windows installation hesitates with this one program - the possibilities are countless. I doubt whether AntiVirus software would do it, though you say it is disabled only one or two services/processes are suspended when 'turned off' while the rest chug away in the background, still active. The only real way to check AV affect is to remove it altogether, though as I said this isn't the likely cause or all software would probably be affected.

You could also try using Process Explorer (another SysInternals tool) to kill obviously running processes one by one and try saving again - there has to be something killing it. Of course, if it turns out to be a vital Windows system you won't be any closer to fixing the problem, but you'll have narrowed it down a bit.

Ah, the joys of computing!

[rgoudie]

Ah, the joys of computing!

Quite the joy.

I am connected to a network, and have a number of mapped drives, which shouldn't be anything unusual.
I'm not willing to modify my basic system configuration. I need mapped drives and an anti-virus program.

As mentioned (numerous times, I know), this is the only program that hesitates before saving. I have literally opened every other program on my computer that can save a document to verify that there was no issue before having made that statement at the top of the thread.

To the WeBuilder development team: is is possible to have a version of the program that does not do what Process Monitor calls a QueryDirectory operation at the start of the save process? Perhaps just open the target file, which has it's own explicit path, so there is no need to check directories. How about a switch to disable it???

Thanks.

-Ray.

[reacher]

I didn't make myself that clear; what I meant was that WeBuilder might be having issues with paths to drives that are no longer there but are still referred to in your registry, not with drives still connected and valid. For example, many users in days gone by experienced Windows trying to access their 'A' drive (floppy disk drive) whenever trying to open the File Manager or (in later versions) Windows Explorer. This was checking to see if a disk was present and if so, would then be ready to display the contents. Windows does the same things today with both fixed and optical drives, firing off the laser/head to check if there's a disk present and ready before opening Explorer to browse files; this can cause annoying delays and is also tied in with the whole autorun/autoplay system which has been expanded even further in later versions of Windows, making some problems worse. One of the first system improvements I make after installation is to turn off autoplay on everything except fixed hard drives; this speeds Explorer up measurably and also provides better system security by preventing autorun-bourne viruses to launch without intervention.

That's all beside the point anyway; networked drives and removable drives which are disconnected but still referred to in the registry just make this worse, so when a QueryDirectory event is checking to make sure paths and drives exist before any other processes begin, this can cause significant delays. I would think (not that I'm a programmer's rear end) that this is either hard-wired into the Windows APIs/Libraries being used or is hard-wired into WeBuilder; why it only does it with that software indicates this might be singularly a WeBuilder issue - I know some of the file management code is proprietary to WeBuilder so this is likely the case - but it still all sounds suspiciously like problems of old when Windows was way shittier than it is now.

Of course, I might very well be way off base as well.