While I have no fix, I have a suggestion: if you open the Progress View (Window>Show View>Other>Progress), watch that while experiencing this “long time to close”, and you may get some insight into what’s amiss. Obviously, it’s not supposed to take a long time; conversely, I’ve not heard this as being a common problem, so it’s indeed odd that you experience it on 2 machines.
Here’s another variable to consider: is this file on a network share or anything other than a local file? Is it connected to source control? Is there any other factor in your setup that may differ from others (extra plugins you’ve added, etc.)? And what about the code in the CFML itself: does it have lots of dependencies on other files, perhaps (lots of includes, or CFC calls, etc.)? While that should not hamper the speed of closing the file, I’m just throwing out all I can think of that might have some impact.
It’s indeed a shame when someone has an experience with CFB that leads them to think it’s broken. The challenge is in finding out exactly what is amiss. It’s not always that obvious.
PS Also, what about the CFBuilder/Eclipse log, availble via the “about” menu? That may give you some insight. You can view it from, In Windows, Help>Product Details>Configuration Details>View error log, and on OSX it’s Adobe ColdFusion Builder>About Adobe ColdFusion Builder>Configuration Details>View error log.
Thanks for the reply Charlie.
It takes long to close a file no matter whether is on the network or in my local hard drive. I have the network files on source control (VSS Plugin), which I thought this could be the problem, but even if the file is not in the source control it is slow closing it. Also even if the file contains code snippets is still slow closing.
The VSS plugin was the only plugin I added, everything else came with the installation.
I looked at the log files and could not find anything that could be related to.
This is still a mistery to me.
I had to unistall CFBuilder 2.0.0 and install the CFBuilder 2.0.1. Initially the files were closing fast but after few hours they got slow again taking about 6 seconds to close each file. Every time I delete the foldings.data file and a new one is created the files close fast, but it seems that something start building up that within few hours they again take a lot of time to close.
Ah, my bad. I was mistaken: it’s not under “other” but rather under “general”.
But in the vein of “teaching one to fish”, did you know that typing the word “progress” (without quotes) in that filter text prompt at the top of the list of views (as shown in your screenshot) would have found it for you? That’s how you can find something in CFB that you can’t otherwise locate on your own.
As for the growing foldings.data file, that may be an interesting clue. Have you opened that file with an editor or text file viewer? It’s got some binary data, but it may be interesting still to look at. I just looked at mine, and it’s got about 8 lines of data (and the file size is just a couple of k). How large is yours (in lines and bytes)? In mine I can see references to files (some currently open, others that I’ve long ago closed).
BTW, while the filename “foldings.data” might suggest that this is related to the code folding feature in CFB, I confirmed that at least for one of the files listed in there, I saw no code folding in effect. Maybe someone else will know more.
One other thought: when you say that it’s initially faster and grows slower, are you talking over a single CFBuilder session? If so, I wonder if you closed and reopened it, if it would also start over being “faster”. If so, then I would wonder if you may be running out of memory. The default heap size is pretty small. For more on changing it, see this older entry (seems Adam’s site is no more, so here’s a tinyurl link to an archive.org copy of the page: http://tinyurl.com/ca5jwan).
Finally, related to that, you can also watch the heap use from within CFB via Window>Preferences>General>Show Heap Status, which shows a progress bar of memory usage (and offers a widget to try a garbage collection as well).
Hope that helps.
Charlie, thanks for your time and information responding to this issue. They were helpful to track down what the problem is.
Based on the information you gave me above I noticed the following.
Under the Progress View what I see when closing a file are messages related to building workspace as the picture below shows.
As for folding.data file, I followed your advice and opened in a text editor. The file content has, like you said, some binary data, but also contains the strings "file:" followed by the full path for the files that I closed. I looked at the size of it and it was 11k with about 11 lines. Then I started to open and close some file and noticed that CFBuilder was writing the names of all the files I close to the folding.data file, which increased the file size. Now the file has 14 lines and 14k. The previous folding.data files had size varying from 38k to 87k. I also note that the CFBuilder was not appending the most recent files to folding.data as the path for the most recent closed files were in the middle of the file content. It seems that CFBuilder was not only updating but re-creating the file with the previous content and the string with the new file path in a random fashion.
When I said that the closing of the files is initially faster and then gets slower, I meant to say that is faster when I delete the folding.data file and CFBuilder creates a new one. As CFBuilder starts updating the folding.data file it gets slower. After that it continues slow even in between CFBuilder sessions.So I think that might be a threshold related to the file size that makes the process of closing files slow.
I don't think the problem is related to memory as I already had the Show Heap Status view on display and even when there is not much use of memory closing the file is still slow.
At this point what it looks like is that the process of closing a file inside CFBuilder updates the folding.data file and when that file reaches a particular size, it takes some time to actually close the file as if CFBuilder was waiting for the folding.data file to be updated. What intrigues me is the fact that this behavior happened in w different PC's so it has to be something related to the setting of CFBulder in handling the closing of files.
I was wondering if there is some sort of setting related to closing files in CFBuilder.
Once again, thank you very much for your responses.
Glad to hear that the info helped. And yes, that info on the files is what I meant, when I said, “I can see references to files (some currently open, others that I’ve long ago closed).”
So as for the size, I would say that these file sizes you are mentioning seem too small to be significant, but who knows. Here’s a potentially interesting question: where are the files (the foldings.data file), relative to CFB? Are they in a folder on the same drive as CFB? In another location, like a network drive, or a mapped drive that may be on the network?
Also, you mention the build workspace info in the progress view. That’s just the sort of thing I was talking about might explain what was amiss.
Related to that, you ask about features which may affect file closing, but while there is in fact a setting that affects startup and that building of workspaces (Preferences>ColdFusion>Server Settings), none of them are related to file closing.
I hope that perhaps someone from Adobe will pick up on this and offer you more info, either based on something they may know, or other diagnostics you can undertake.
The foldings.data file is on the network on a network drive. I have the workspace setup on the network on a mapped drive.
However, if I open a file (not in a project) using the File view that is my local PC, closing that file also is slow.
Sure, but I wonder if your doing that could still be stored in that foldings.data on the network.
Try opening a new workspace, whose location is NOT on the network. See if that may not make a difference. (For most CF devs, the workspace location is not really important to how they code, so it should not hurt other than that you will lose any config settings you made. But you can always open the original workspace to get back to that point if you prefer.)
I'm experiencing this exact problem in an evaluation version of CFB2.
My workspace is indeed on a mapped network drive and that is where is should stay. I develop against an in-house Windows Server.
I've been using CFEclipse for years (and really like it) but am evaluating CFB2 due to non-support of that project.
CFEclipse closes file in less than a heartbeat.
In CFB2 it takes *forever*. Not good!
There must be a fix!
(Not directly in reply to Charlie, but apparenly you can't reply to the thread, it has to be to a person)
This is a really annoying problem. It only takes a few hours until closing a file takes more then a few seconds, it's very irritating. Yes, most of the time the projects are on a network drive but it should not take this long to Close a file, but I could understand if it did for opening. Funny side note: It's actually faster to open files than close them.
Fix this in your next release Adobe...
I found this thread after experiencing the slow file closing issue at a new job where the website files are all stored on a network drive. I realized that the Workspace files are also stored on a network drive. I'm in a Windows environment where the user's files are stored on a server. So when I installed CF Builder 2, it automatically put the workspace directory in my user's directory which is on the server.
After reading this thread I decided to try moving the workspace to my local C: drive. I closed all projects and then went into Windows - Preferences and filtered on "works". Under Startup and Shutdown there is a Workspace setting: "Prompt for Workspace on startup". This was unchecked because I had previously told CF Builder to just always use the default. I then closed CF Builder.
I copied the Adobe ColdFusion Builder Workspace directory from the server share to a new directory on my C: drive. Then I restarted CF Builder. It prompted for the workspace where I browsed for the new directory and again checked the "Use this as default...".
So far the file closing slowness has gone away. Other things such as opening and closing projects, refreshing files in a project and searching across many files seems faster. I know this is an old thread, but perhaps it will help someone.