Editor: Pressing ctrl-G takes 20-30% CPU and 2-4 seconds to

[paul55]

Here's a thought: you could run Microsoft's Process Explorer (http://technet.microsoft.com/en-us/sysi ... s/bb896653) on Flare; double click on the Flare process and go to the Threads tab; sort by the CPU column and use the Stack button to see what the busiest thread(s) are up to.

In my case, it didn't reveal much about the high CPU usage when scrolling through text in the editor -- it seemed to be in System.Windows.Forms.ni.dll most of the time, but I can't tell what it's doing in there. But maybe in your case there's some other software layer or place in the code that's bogging it down?

HTH,

-Paul

[samjones6]

But maybe in your case there's some other software layer or place in the code that's bogging it down?

The layer (that I care about) is: Flare

Digging into the Flare internals isn't my job (better or worse). We have Gold support with Flare, and they can dig, if they want to (they haven't wanted to, their call!).

[LTinker68]

I don't think Paul was suggesting you dig down -- I think he was saying there's something in your work environment that most people don't run into, at least not to the extremes you're seeing. Something like that might make it hard for MadCap to track down since there could be any number of variables that could be impacting it, but hopefully they'll be able to figure out what it is. It could be that something in the .NET platform that Flare relies on so much is hindering them significantly in this case. I haven't used RH in years, so don't know if they use .NET at all, but if not and .NET is the culprit, then you might be better sticking with RH. Hopefully that won't be the case, though.

[samjones6]

I don't think Paul was suggesting you dig down -- I think he was saying there's something in your work environment that most people don't run into, at least not to the extremes you're seeing. Something like that might make it hard for MadCap to track down since there could be any number of variables that could be impacting it, but hopefully they'll be able to figure out what it is. It could be that something in the .NET platform that Flare relies on so much is hindering them significantly in this case. I haven't used RH in years, so don't know if they use .NET at all, but if not and .NET is the culprit, then you might be better sticking with RH. Hopefully that won't be the case, though.

LTinker, Paul, and all the hard working folks on this forum: You all get an A+ for effort.

Thing is, I am a developer. In fact, I am a Visual Studio, .NET developer.

I know a TON about .NET. I use .NET all day every day, etc etc.

The problems I am experiencing are IN FLARE.

Fishing around my PC is... a fishing expedition.

The problem is Flare.

[RamonS]

The problem is Flare.

So I assume your software is much better and flawless?

[samjones6]

So I assume your software is much better and flawless?

This forum is a Flare forum.... my comments relate to Flare.

My users have no problems telling me what they think of our stuff.... but this isn't the forum for that.

Speaking of which: Has anyone here tried Robohelp v9?

[RamonS]

My point is that blasting everything in Flare gets old. As a developer you should know that Flare's WYSIWYG editor is a massive piece of complex code that is to be run on a rather volatile platform, which may explain why only you seem to have everything and the kitchen sink go wrong in Flare (not saying that it doesn't). I just wonder how it would come across if your users go out of their way to report every issue they find in your app in public (regardless if it is a flaw or not, maybe they just have a bad day) and at the same time alienate other users (calling them dumb and that they won't get things anyway) plus constantly ask and brag about how awesome the competition is while complaining that everyone is just mean and doesn't want to help. Harsh words? As ye sow, so shall ye reap.
So, to get to your question (which I wonder why you ask it here, since it is a Flare forum): I haven't used RoboHelp in years and I'd be surprised if it is drastically better then the last time I used it. When I switched to Flare I was missing so many things just to find out that the MadCap approach was miles better, especially when working with larger projects where RH klonked out, because it just could not scale at all. RH was just craptastic on so many levels. But since you suggested on multiple occasions that RH is so tremendously superior to Flare I recommend downloading the trial version of RH9. Do you need the link?

[samjones6]

My point is that blasting everything in Flare gets old.

You are telling me!

I spend almost as much time submitting bugs to Madcap as I do editing in Flare!


The bottom line is that Flare was sold to us as a viable replacement for Robohelp, and it fails to achieve this.

The Flare editor is (as I have said) the junkiest editor of any kind I have ever used.

I am impressed at the fortitude of you and others on this forum.

Yes, I spent a few minutes with Robohelp v9 yesterday, and it rocks. It has almost everything Flare has (variables, multiple TOCs, single source publishing, etc), a blazing fast IDE, can be used from the keyboard, and the editor works.

I don't know how to get to RH from where I am now (having just spent 2+ months converting the project to Flare).

But let's not kid ourselves: Flare is really green. Simple example: On half the dialogs, the esc key works... and on half it doesn't.

Tasty!

[samjones6]

v7.1 has the same issue.

[nickatwork]

v7.1 has the same issue.

I was able to reproduce this.....then not reproduce it.

From what I found, inserting an image will load from the last directory that you used to place an image in a topic.
In my project, most images are in 1 folder, some have been split out. Anyway. If I insert from the 'main' images folder (1000+ images), CPU load jumps and time taken to open the screen is a few seconds.
If I do the same thing, but with a brand new project with 2 images in the folders, it opens immediately, and with almost no CPU load.

From this, I'm guessing that Flare is somewhere/somehow starting to cache and preload those images before displaying the window, I have over 1000 images, so thats a lot of files to get ready, and they are images - not exactly small file sizes. Once that folder is loaded, I can flick down through every image with zero lag and load time for the thumbnails. I'm guessing that preload time when opening the insert image box is being caused to offset lag when the window is actually open.

The same kind of thing happens if opening the images folder in the Content Explorer...it takes a few seconds to populate that whole list.

[RamonS]

It may not even be Flare, but Windows. I work with folders that contain hundreds of files and even with File Explorer the time to display is quite long. It even gets progressively worse with newer Windows versions. The last zippy version was 2000, after that performance on Windows went down the toilet.

[nickatwork]

It may not even be Flare, but Windows. I work with folders that contain hundreds of files and even with File Explorer the time to display is quite long. It even gets progressively worse with newer Windows versions. The last zippy version was 2000, after that performance on Windows went down the toilet.

Yup, I see the exact same thing if I'm viewing this folder in explorer, or any folder that has loads of content. Simply caching that many files takes time and strains CPU.

[RamonS]

What is even worse, there is really no point in caching all the files, although I wonder if the files themselves (meaning their content) get cached rather than the file properties. I have to try out if turning off viewing some properties has any impact. Still, sometimes I really wonder what Windows is doing, especially when it spends minutes to think about deleting files when all it has to do is whack the entries in the file table. Even DOS is speedier.

[Andrew]

Typically, for me, Flare is MUCH MUCH slower than Explorer. My projects with 500+ topics in one folder (and I have 30 some-odd folders), I can browse through them in Explorer in no time at all, whereas Flare takes 3-4 seconds to click from folder to folder.

Also, given that samjones6 has the same problem in a folder with almost no images (a default project), it suggests the number of images is not the issue. In my project with over 700 images in one folder, it takes about 4 seconds to open the Insert Image dialog the first time, then 1.5s after that. In an empty project, it's more like 1s (which is, quite frankly, very slow -- I see no reason it shouldn't be near-instantaneous in an empty project -- but since it doesn't impede my workflow at all, it doesn't really bother me).

[samjones6]

It may not even be Flare, but Windows.

The issue I see in this area is %100 Flare.

It appears that every time I press ctrl G, Flare does several things:

- Reads a list of all the files // super duper fast in windows
- Reads all the .props files // horrible slow, because Flare is really slow dealing with xml in general
- Builds a colorful color coded list

The perf issue here is pure Flare. Please do not muddy the topic by talking about the OS.

[samjones6]

Typically, for me, Flare is MUCH MUCH slower than Explorer. My projects with 500+ topics in one folder (and I have 30 some-odd folders), I can browse through them in Explorer in no time at all, whereas Flare takes 3-4 seconds to click from folder to folder.

Correct. This is also my experience.

Flare performance is horrible:

- Pressing ctrl G
- Opening the project
- Opening topics
- Opening a subdir in the project explorer

Just looking at memory usage shows some of the issue. Flare is the #1 consumer of RAM on my system, often in the 150-250mb range.

The issue ain't Windows. The issue is Flare. (And Madcap support has confirmed most or all of the issues I have submitted in this regard.)

[nickatwork]

150-250mb of RAM.....jees I wish half the tools I used were that light. Flare runs hotter than that most of the day on my box, let alone things like photoshop, flash, MS Word....Even good old (insert sacastic tone here) Lotus Notes kills around 120+ and thats during idle. Considering that most PCs these days are easily 4GB+ using 150mb doesnt seem too hard.

[RamonS]

Can easily add SQL Server and Firefox to the list of apps that easily use more than 150MB RAM without really doing much.

[samjones6]

150-250mb of RAM.....jees I wish half the tools I used were that light. Flare runs hotter than that most of the day on my box, let alone things like photoshop, flash, MS Word....Even good old (insert sacastic tone here) Lotus Notes kills around 120+ and thats during idle. Considering that most PCs these days are easily 4GB+ using 150mb doesnt seem too hard.

Please stay on topic.

I wouldn't care how much RAM Flare takes EXCEPT that it takes that much AND is a dog.

It's doggishness is (from my observations) related to its resource use. For example, Flare doesn't build an image of the index on disk. Rather, it builds the index dynamically by reading ALL the topics. This index is then held in... memory.

So instead of working with a single file that holds the index (or a cached built copy of the index), Flare has to build the whole index in memory, and has to scan several hundred topics to do it.... every single time I press Refresh to see what the index looks like.

The problem this thread is discussing is: Flare is horribly slow as a user experience.

We appreciate thoughts on this topic. Thoughts about Firefox, SQL Server, whatever, are for another thread, please.

Thanks!

[RamonS]

The single file on disk approach is what RH uses (used?) and it just doesn't scale well. Besides that, accessing from memory is always fast than any disk I/O. So what you are asking for is making Flare even slower and less scalable? Besides that, the RH approach was (is?) notoriously buggy. Can't count the many times the files were out of sync and had to be fixed. I rather have the HAT make a fresh instance that is accurate each time.

[Andrew]

It's doggishness is (from my observations) related to its resource use. For example, Flare doesn't build an image of the index on disk. Rather, it builds the index dynamically by reading ALL the topics. This index is then held in... memory.

So instead of working with a single file that holds the index (or a cached built copy of the index), Flare has to build the whole index in memory, and has to scan several hundred topics to do it.... every single time I press Refresh to see what the index looks like.

Frankly, I don't think MadCap has done enough to deal with large projects -- Flare's architecture does not seem very conducive to it. Of course, the specific issue you asked about in this thread has nothing to do with your project size, given that it occurs regardless of project size. You are a developer. Not many other folks can duplicate your 4-6 seconds. What does that tell you?

That said, in this case, there is a reason for how they implemented the index: the old RoboHelp method meant that if you condition parts of a topic that contain the keyword you've associated with the topic, the keyword *also* gets conditioned automatically. The old RoboHelp method meant you had to condition the index too.

[samjones6]

That said, in this case, there is a reason for how they implemented the index: the old RoboHelp method meant that if you condition parts of a topic that contain the keyword you've associated with the topic, the keyword *also* gets conditioned automatically. The old RoboHelp method meant you had to condition the index too.

Uhhhh, Robohelp X5 does not behave the way you discuss above.

In RH, if the topic is excluded, then the index keyword is automatically excluded. No index-based conditionality needed.

Automatic, hands-free, and reliable.

The Flare method of indexing is a real hassle. As I add index keywords to a topic, these changes do not show up in the Flare index view until I save the topic AND refresh the index. This would be a pita in itself, but Flare takes some seconds to refresh the index (cause it has to scan all the topics), making the process a real joke.

[samjones6]

You are a developer. Not many other folks can duplicate your 4-6 seconds. What does that tell you?

Well, there are two to four folks here on the forum reporting the same issue I am reporting.

And Flare support has seen the issue.

And it has been submitted to the Flare product manager.

And no one disputes that there is an issue in Flare (except a few folks here on this forum who defend areas of Flare that Flare support acknowledge are problematic).

What does that tell you?

[nickatwork]

Please stay on topic.
The problem this thread is discussing is: Flare is horribly slow as a user experience.

We appreciate thoughts on this topic. Thoughts about Firefox, SQL Server, whatever, are for another thread, please.

Thanks!

Nothing off topic about it. You raised the RAM usage issue, I simply pointed out that the amount of RAM being used is not high compared to other common programs that peopl have.
Anywa, I thought this thread is discussing the Insert Image (CTRL G) function in Flare.....it seems to be bouncing around from that to other 'Flare is a dog because of X' and 'RoboHelp does X, I wish I had RH' posts...All this thread is turning into is Flare bashing - deserved or not...

[samjones6]

All this thread is turning into is Flare bashing - deserved or not...

If Flare support, or anyone on this forum, (or anyone, anywhere) can help the Flare IDE run comparably as fast as any other software on my machine, I will be most grateful.

The issue has been that while multiple users see the performance problems, and Flare tech support has seen most or all the issues, no one has been able to help me (or other users) resolve the issues.