Is anyone else having frequent frozen editor problems?

I am using Coldfusion Builder 2016 and I still have it freeze up occasionally.  Sometimes just for a little while and it comes back but other times it freezes up and I have to force it to close.  Whenever I tab in a group of items it freezes for a little while before actually performing the tab, which seems strange.  Anyway, never found a solution for me yet and I have the latest updates.

I finally solved my problems on Windows 7 64bit with the Eclipse plugin by forcing Eclipse to use the jvm.dll rather than let it use the javaw.exe executable which it uses by default.  My setup was Win7 64bit, Eclipse 64bit, and 64bit JVM.  I experienced all the problems you describe, and more, but since making this change CFB runs teriffic and I was able to turn all the crap I had turned off 'for performance reasons' back on.

Just going to paste the blog post I made about it.  Note that this is 64bit stack-specific, and that CFB standalone is 32bit, so if you want to try this on the standalone install you'll need to make sure you've got a 32bit JVM (one comes with standalone, but you can install a newer one from www.java.com as well).  I haven't tried this with standalone, only the Eclipse plugin, but if you're experiencing similar issues you might get the same benefit by doing the basics of what's outlined below:

_________________________________________

Original url: http://www.websolete.com/posts/cfbuilder-2-performance-problems-on-windows-7-64-bit-solved

For those of you that continue to experience hangs and massive slowdowns running CFB on Windows 7 64bit, the one thing I found that made all the difference in the world is to have Eclipse use the jvm.dll rather than javaw.exe (the default).  I’m using the CFB plugin into Eclipse, but I suspect this may also apply to CFB standalone on Win7 64bit as well.  No amount of configuration changes, switching between 32 and 64bit JVM/Eclipse or disabling of features made any difference to the significant performance problems I was continuing to experience UNTIL I explicitly had Eclipse start up using the dll (forcing the JVM to load within the Eclipse process). 

I also found that simply adding the –vm argument to the eclipse.ini apparently doesn’t work when trying to specify a specific JRE to use (at least on my machine); regardless of the existence of this argument in the ini file, it will still always fire up C:\Windows\System32\javaw.exe, which is where the problems I was seeing are (high CPU utilization, memory consumption). Not sure why that argument is ignored, perhaps a path issue, but I found that the only way I could be certain that I could run Eclipse with a specific JRE was to invoke Eclipse with the –vm command line argument.

I removed all my old JRE installs and installed the most recent 64bit JRE to C:\Java\64bit\.

What didn’t work:

I first tried updating eclipse.ini with:

-vm C:\Java\64bit\jre6\bin\javaw.exe

but found that Eclipse was still invoking the C:\Windows\System32\javaw.exe for some reason.  Eclipse started of course, and the javaw.exe process started going bananas again every time I would try to edit a file and *change the value of an html input tag* of all things – as soon as I changed the input value by adding one letter (even before saving) the javaw.exe process would immediately start eating cpu and memory, and I could repeat this problem consistently across multiple files.  Eclipse would hang, and I’d have to forcibly kill it as it would never recover.

I then tried invoking Eclipse with the command line –vm argument, like so:

D:\eclipse\eclipse.exe -vm C:\Java\64bit\jre6\bin\javaw.exe

leaving all the other arguments alone in the ini file; now, I could see that it was definitely using this particular javaw.exe but had exactly the same behavior I described above, edit a file (local filesystem, not network just to clear that it isn’t network related) and javaw.exe freaked out and Eclipse hung until forcibly killed.

I then tried changing the –vm argument in the eclipse.ini file to:

-vm C:\Java\64bit\jre6\bin\server\jvm.dll 

When Eclipse started it still had fired up javaw.exe in the Windows system32 directory as above. Whatever.

What worked:

Finally, I invoked Eclipse using the command line –vm argument pointing to the JRE’s jvm.dll, like so:

D:\eclipse\eclipse.exe -vm C:\Java\64bit\jre6\bin\server\jvm.dll  

and holy crap, it runs great.  Responsive, no appreciable sluggishness, I even turned a bunch of the code assist and insight features back on in light of how great it works now.  Because javaw.exe isn’t running I have seen none of the problems I had when using the default invocation.  I don’t understand why this option isn’t talked about more (I recall seeing only one reference to it in all the stuff I read), nor why it works better for me than the default javaw.exe but I’ve been running it all day now and it has been working terrific so far.

So, if you’re on Win7 (or maybe even Vista) 64bit, have a 64bit JVM and 64Bit Eclipse and are seeing crappy performance or stability, try this method and see if it doesn’t solve your problems.  Off now to uninstall IntelliJ and Komodo trials ….

You may also need to turn off the Quick Fix in the syntax checking, I've seen issues with that depending on how you code (I use Coldspring a lot so it's marking tons of lines as invalid).

I find CFB2 far more stable than CFB1. I did need to install it as a plugin as I also use FlashBuilder and I had trouble getting them to use the same workspace when either was installed as standalone with the other as a plugin. With both installed as plugins, seems to work fine.

I'm having pretty frequent unresponsiveness since I installed CFBuilder as a plugin to my Eclipse installation. I'm hoping maybe someone can help me work this out because otherwise, I'm liking CFBuilder and I'd like to continue to use it. Here's my setup:

Windows: 7 x64

Eclipse: Indigo

JRE: 1.6.0

CFBuilder: 2.0.0.277745

Thank you for any help you can provide.

Honey

I have had sluggish editor issues, where it pauses for 1-3 seconds while I'm typing, and then catches up by displaying blocks of typed characters all at once. Also code coloring has been extremely slow. This seems to particularly happen in large files (>1500 lines).

I was able to fix the issue with the following steps:

1) Delete the project in Navigator. Don't remove the files from disk of course.

2) Archive the .projects and settings.xml files from your project folder to some safe place if you want.

3) Restart CF Builder, then re-create the project.

Voila!  For me, anyway.  I have been able to restore my settings.xml file afterwards and have CF Builder pick it up with no issues. I haven't tried restoring the .projects file, but I compared the archived version with the new one created by CF Builder and they were identical for me.

I've been able to go for a few days before the sluggishness shows back up, and then I have to repeat the above steps. I've sent dsarkar@adobe.com an email so hopefully they can get to the bottom of this.

Freezes all the time. Like several times an hour. Sometimes for a few seconds, sometimes can only be terminated by Task Manager.

It does not take processor resources or more memory - it just stops responding and stops displaying anything but some menu icons and some scrollbars.

Apparently setting code assist to 0 milliseconds delay kills it.

Especially if you type inside the cfquery tag - (it looks like it connects to the RDS and tries to pick up all available table names from the datasource),

Well maybe it is helpful but why does it take so long, and why does it keep offering the table name even after WHERE clause?

It would be nice if it worked like the query editor in MSSQL2008

Or if you type and leave a tag unclosed, and then decide to type something else on  another line - oops! Not allowed.

Like type <cfset myvariable = > or type <cfif and then start typing somewhere else, inside another tag - likely to freeze for at least a couple seconds

Maybe it works fast enough on machines with dual processors and 15k harddrives, but as is, it looks like an IDE for slow-typers

And then this annoying habit on unfolding a folded code block arbitrarily and unexpectedly when you are typing below it - takes the line you type way down where you cant see it. Instead you see the unfolded code block.

The build 270225 that I have definitely seems to have cleared up the freeze issues, at least for me. Much more stable than the initial beta 3.

The one issue I have that still really drives me nuts is the auto-scrolling issue mentioned in the other thread. Trying to select text that is off the right-hand side of the screen in particular is often like trying to catch a butterfly with your bare hands.

I can only confirm that I'm also seeing the problem, on OSX 10.5, and have to kill CFB and restart it. It has, on occasion, locked the entire operating system up, and I could only kill CFB by typing the Force Quit shortcut keys.

It happened twice while I was coding a CFC written in all script style.

Is there any update on these freeze issues? I have been experiencing the same problems with the 3rd Beta release. This is becoming extremely frustrating.