Is it me? Or is it Flare 12?

[salem16]

Just curious whether anyone out there has found v12 to be significantly slower and buggier than previous versions. My company has used Flare for 10 years, and the product has never caused trouble. With v12, our project loads much slower, the search and replace feature forces Flare to close, we're unable to start typing for the first ten seconds after creating a topic, deleting topics takes forever, etc. For the first time in ten years, Flare is causing us to fall behind. Nothing is different on our end, nothing has changed except the version of Flare. I submitted a bug, finally heard from support, tried everything I was asked to try, and the problems persist. Anyone at all out there experiencing anything similar? I mean, misery loves company, right?

[roboHAL]

I responded to a similar thread of yours. I agree there are some undesirable aspects to V12, however, for my particular purposes it is usable and I can find nothing compelling to force me to revert back to V11. I remain confident MadCap will collect all the issues and introduce fixes/patches, hopefully in an expeditious manner

[wclass]

Someone else posted comments about slow Flare and has suggested turning off the Analyzer options.
See: viewtopic.php?f=13&t=27091

[RamonS]

I did not encounter any performance differences between v11 and v12. Makes me wonder if it is dependent on project.

[roboHAL]

wclass, I can give that (Analyzer off) a try but I'm rather sure it would be to no avail (at least in my case). Reason being is that whenever there is an issue that is reported to MadCap, one of the first things the tech support reps asks that be done is to delete the Analyzer folder. That has never helped me. I do have a suspicion what is causing performance issues. Source control. In my case I use TFS 2015. When I use the exact same project NOT BOUND, all around performance is noticeably and obviously much improved. I do have the option selected whereby Flare is instructed to prompt if files need to be checked in. However, I had that same option selected in V11 and its performance is noticeably better.

[RamonS]

I, too, use TFS 2015 and checkins are a tad tardy. That may have to do with Flare now checking TFS project rules such as requiring a comment for checkin or adding TFS task reference numbers. Unfortunately, Flare's implementation is totally reactive. That means it won't tell you right away that you need to add a comment, it will proceed with the checkin and then tell you wayyyyy at the end in small print that it failed. So if you see the source control window hanging for a long time you might want to look at the messages listed, maybe it complains about something. Odd thing is that at least for me in one case the dialog close itself after a while although none of the files were checked in. I already complained and suggested making Flare more proactive as in providing warnings that comments and such are needed. That information can be retrieved when getting the files or explicitly querying TFS for the project rules.

[ChoccieMuffin]

Because of the frequently reported performance issues with source control, we don't use the Flare integration. It's an extra step (and yes, it's prone to human error) but we have finally got our heads round the process of doing SVN adds and commits, and only keeping in source control stuff that is managed within the specific project rather than also adding stuff that is imported using global project linking which we use A LOT.

Would your company processes support NOT using the integrated source control? I'm sure you'll find the performance will be noticeably better.

[salem16]

We use TFS, also. It's always worked smoothly with Flare--well, always enough, thanks to sharp technical folks. I haven't noticed anything different about the check-out/check-in process, but the overall sluggishness and inability to use search and replace persist.

Anyway, MadCap has scheduled a remote session with me tomorrow. I'll report back.

[mattf]

salem, I'm really eager to hear what you learn. I just upgraded to Flare 12 a week ago and I instantly noticed delays in keyboarding. Flare has never acted like this before. I immediately recalled seeing your post a while ago so I've come back in hopes that you've found a solution.

BTW, I had to laugh when I read the comment above about the first troubleshooting step always being disabling Analyzer. I've had the same experience, and it never helps anything. I personally think that there is a classified government study being conducted around that.

With breath bated...
-mattf

[salem16]

As promised, the latest: MadCap spent an hour-and-a-half on a remote with me today, troubleshooting issues with the performance of v12. We learned the trouble appears to be tied to a .dll associated with Windows 7 and the decision to "get latest" when loading a project bound to source control. According to the support rep, he's seen a handful of similar tickets for v10 and one for v11 and has just begun to see them for v12. He said he hasn't seen any tickets related to this issue from anyone on Windows 10. Armed with information he obtained today, he's pulling in development and will be in touch as soon as they have a resolution.

Unfortunately, due to other software we're using, we're not yet able to upgrade to a higher version of Windows, but it sounded to me as though getting on Windows 10 (or at least a higher version than 7) might be the quick fix (but don't quote me).

[mattf]

salem,
Thanks for this. I'm on Windows 7 and in the same situation. Hopefully they can fix it in a patch.
-mattf

[salem16]

Uploaded our project to MadCap, where the issue was replicated and a bug report was submitted to development. I'll provide an update when I have one.

[KCinColorado]

I'm running Flare 12 on Windows 7 too, using TFS source control. I ran into an odd bug where if I Zip Project (to send to MadCap support), say Yes to the prompt about removing the zipped file from source control, and then exit Flare, the next time I open that project, Flare encounters all sorts of errors around mapping and will not start. (Encounters an error, needs to close, please send report, yada-yada.) We discovered that Flare had deleted the working folder in TFS. So we redefined it and I was able to work with the project again with no errors. Until I zipped the project again, then the same thing happened. Flare deleted the mapping in TFS and could no longer open the project. Argh!

I reported this as a bug but MC Support cannot recreate it with a sample project and neither can I. Just my big existing project which was working with TFS just fine before I upgraded to Flare 12.

I THINK my TFS definitions are local. In the sample project I created today, allowing Flare to bind to TFS, the mapping it created does not appear in the edit workspace dialog in TFS so I'm assuming it created that on the server? (Not even going to pretend I know much about TFS other than check in/check out...).

[roboHAL]

KCinColorado, I believe the problem you are reporting is avoidable. First, Flare prompts to create a zip file the content of which is unbound from source control, not the zip file itself. Secondly, when Flare creates the zip, the program prompts for the location of that zip. Default behavior when/if you use that zip is Flare will unpack to the folder it is in. Therefore, it is conceivable you are overwriting files and/or unpacking the unbound content to the very same folder that you have mapped in TFS. This will create the condition you are reporting. The remedy is to create the zip and unpack it in a completely independent folder from the project.

[KCinColorado]

Unfortunately that isn't the issue. I have never unpacked the zip file. All I am doing is reopening my normal project AFTER creating the zip file, renaming the zip file, and sending it to MadCap. And Flare crashes on opening.

[roboHAL]

I see. Here is what I suggest in this case. First, create the zip without choosing to unbind from source control and observe if the problem still exists. That may be useful info for MadCap support regardless of yes/no. They can work with the zip file even if the content is bound to source control. Second, instead of using Flare to bind to TFS, do the reverse and use TFS to bind to your project and observe if the problem still exists. That too may be useful info for MadCap support regardless of yes/no.

[salem16]

Maybe I lucked out. Since I was on a remote session with a MadCap rep, I let him do the zipping, and all I needed to do was the uploading. Still no word on a fix for our v12 problems. In the meantime, we've gone to v11, which seems to do a bit better with Windows 7. At least the search works much better. It's still slower than v9 (our previous version) but tolerable. So far.

[Scotty]

Has anyone with 64-bit performance problems had better performance with the 32-bit version?

[BrianBXYPRO]

I'm definitely finding Flare v12 buggier than v11. For example, just this morning Flare crashed when I clicked Ignore All during a spell check. (This is not the first time that this has happened.) I've also had issues with my print outputs (as I mentioned here viewtopic.php?f=10&t=21392), which never happened in v11. Performance wise I can't make a comparison since I used Flare v11 on a really old laptop whereas I'm running v12 on a brand new laptop.

Having said that...

I remain confident MadCap will collect all the issues and introduce fixes/patches, hopefully in an expeditious manner

I agree 100%. I have found MadCap to be incredibly responsive so I'm confident these issues will be fixed.

Brian

[Thom_the_bomB]

I wasn't willing to believe it was Flare, but it isn't you!

Full disclosure: I've just started using Flare for the first time so I can't compare v12 to previous versions.

After a day of troubleshooting my machine and network, I found this discussion board and was "glad" to see I'm not alone. I can report the same lag in typing where a whole sentence can magically appear seconds after I've finished pressing buttons on the keyboard. Cursor behavior can also be erratic and I've found that switching from the Text Editor back to the XML Editor can create an unusually large spike to the CPU (20% in my case). Opening larger topics can also be slow. Overall, I'm spending a bit of time watching the computer think.

I'm running Windows 7 (version 6.1.7601 SP 1) and am not using version control, so this issue is not inherently tied to W7 and VCS. Files are accessed from the network, but the same issues were present when working on my files locally. Processor is 3.4Ghz, 4 cores, 8 logical processors along with 16GB RAM, so I wouldn't have expected slowdown from basic editing tasks.

Here's hoping that MadCap can issue a patch for this soon, as it will continue to hinder productivity.

[Nita Beck]

For what it's worth, I don't currently see this lagging in either Flare 11 or Flare 12...

Earlier in this thread, Margaret suggested that one should see how Analyzer options are set and then turn off the things that aren't needed. Having all the Analyzer options on will definitely slow down Flare's performance. (In response to Margaret's suggestion, someone else also said that deleting the Analyzer folder had no result, but I want to point out that that is not what Margaret was suggesting.)

In Flare, go to File > Options > Analyzer and examine what you've got selected. The more things you are asking Analyzer (that is, Flare's built-in Analyzer functionality) to do, the more overhead you are placing on the program. Try tweaking the Scan options and the Performance options to see if performance improves.

I'm not guaranteeing that this will help those of you with the serious lagging issue, but I want to make sure that you at least try to adjust these Analyzer options.

[salem16]

More than a month since the bug was submitted and still no word. In the meantime, we're using v11. Performance is better overall; however, every morning, when I first try to load the help project, the "Querying source control" message (we integrate with TFS) never ends, so I End Task through Task Manager, reopen Flare, re-select the project, and it loads. Had a developer watch the process; he checked a few things in Visual Studio and said it was Flare's problem. So I've submitted yet another bug.

[ChrisBradley]

Flare 12 was running just fine for me, until I was upgraded to Windows 10. Now Flare is very buggy. Almost everytime I press Backspace on the keyboard Flare locks up or the XML editor goes completely blank for a few seconds. I've uninstalled and reinstalled Flare, ensured Windows 10 was fully updated, and it is still very sluggish. The HTML5 and PDF build processs is easily taking twice as long under Windows 10 as before (windows 7).

I have not encountered any issues with other applications under Windows 10, such as MyEclipse IDE, Visual Studio 2012, Photoshop, Camtasia, MySQL, or any MS Office app.

[roboHAL]

ChrisBradley, that's unnerving to read as my organization does plan a win 10 upgrade in the near future. I'm on 8.1 now. I installed Flare 12 on my home PC which is Win 10 and it "works", however, that PC is otherwise not resource intensive enough to run Flare properly (even V10 or 11), so I had no basis on which to make a comparison.

I would suggest you report your issue to MadCap tech support and see what they have to offer in the way of a solution.

[ChrisBradley]

I still have some more testing to do to see if I can determine the root cause. I don't believe the issue is tied to analyzer or source control - I'm getting blank screens on projects not bound to Subversion, and all of my analyzer options are off.

I'm on Windows 10 Pro 64bit edition, using 64bit Flare 12. I have a 512GB SSD, 8GB Ram, and Core i5.

On Windows 7 Flare 12 worked flawlessly for me.