Flare 7 editor CPU usage

[samjones6]

Have you checked in Task Manager that hh.exe isn't running, perhaps even more than one instance? Each time it runs it uses up to 50% of cpu and impacts performance noticably. When running Flare 7 it doesn't shut down after veiwing CHM files so may be an issue for you.
There is a short thread on this (I'll have to learn how to point to it some time.) and a bug fix request entered.
Phil

hh.exe is not running, and has never been part of the problems I have with Flare.

We need to get clear here: The Flare editor is FULL of bugs. Real bugs. Bugs that slow me waaaaaaay down (compared to Robohelp). Bugs that make Flare editor seriously non-standard in terms of behavior, speed of use, ease of use, etc.

I submit bugs daily (sometimes two to five a day) to Madcap. The Madcap team successfully reproduces almost all the problems I report and opens bugs.

I compiled a list yesterday of open bugs that I reported in the March-May frame. It is two full pages long (one line per bug, one blank line between bugs). This list is not "what is in my head" this is a list of items Madcap responded to with "we opened a bug on this, #00000."

• The Flare compiler rocks.
  The Flare architecture is very advanced.
  The Flare editor is an unqualified dog. Both in terms of its intended design (pressing down arrow 10 times to move down 5 lines? Please!) and its quality of implementation (keyboard-hostile design, poorly designed dialogs, inconsistent behaviors, plain old bugs) I am very sad to say this (I have a huge investment of time in Flare, and the company spent a bunch of $ on it), but it is true.

I run 7.0.1 on an Intel Core2-Quad Q9550 @2.83Ghz, 4GB RAM, WinXP

Robohelp (and everything else) FLY on this computer.
Flare drags, and often uses high cpu.

[paul55]

To throw in my $.02 on several of these issues at once...

Re. the bugs: I probably reported a number of the same XML editor bugs in v6, and I've seen that some definite improvements were made in v7, though I agree there is still more work to be done if MadCap wants the navigation, keyboard interface, etc. to behave more like standard Windows apps. But to their credit they have been responsive on the issues I sent in and at least made some progress on those, and it's made the editor a lot more usable for me.

Re. the performance issues: I'm not seeing problems with Ctrl+G or general slowness with the XML editor or Flare in general -- for me it's just when arrowing through text in the XML editor, so for me, Flare is still usable (and I only run it on one system, so I can't compare with any other machines).

Well, the Madcap guys opened a bug on this.... current bug number is 44371.

For Flare Support or anyone else who knows -- is there a way I can view this bug report also, even though I wasn't the one who filed the bug report? I'd like to get an update if/when it gets fixed, if possible.

I run 7.0.1

I haven't gotten an email on the 7.0.1 upgrade -- anyone know where I can download it?

Have you checked in Task Manager that hh.exe isn't running

I do run into that on my machine; haven't found a fix or workaround yet, but it seems unrelated to the Flare CPU usage while navigating through text; that is, if the system (a dual-core) is idle, Flare uses 55% CPU or so, and system CPU is a few % higher; if hh.exe is spinning, the overall CPU usage of the system ends up getting pegged at about 100% -- 50% in hh.exe and the remainder in Flare, basically as you'd expect. But neither one seems to be a cause of the other.

BTW you can include a link in a posting by clicking on the gray URL button above the main edit field, and pasting the URL in between the tags it inserts. For example, here's a link to the Forum FAQ page: http://forums.madcapsoftware.com/faq.php , although it doesn't seem to mention how to embed URLs...

-Paul

[young@heart]

Thanks for the tip Paul. I didn't feel like stumbling around for the answer in the middle of creating the post.
but as you can see here ->http://forums.madcapsoftware.com/faq.php it was very simple (and obvious) just as you suggested.
Phil

[LTinker68]

I haven't gotten an email on the 7.0.1 upgrade -- anyone know where I can download it?

I don't think they generally send emails for incremental updates. Normally Flare prompts you that there's an update available when you open it, but perhaps you have a firewall or setting blocking that notification. If you click on the Help menu and click the option to check for updates, it should bring up a screen that you can click on to get to the download. There might also be a link in the Start page, if you have that visible, although if you have the update notification blocked then your Start page announcements might be blocked, too.

[paul55]

Ah, thanks for the tip, Lisa -- I didn't think to look there. The machine is blocked from Internet access, so I'll have to see about unblocking it (not likely though) or else getting the upgrade link some other way. The Check for Updates command comes up with an empty dialog, no link or anything.

The Start Page indeed doesn't show any announcements or updates, so I guess that's to be expected.

Is there a direct download link anywhere for users on a machine with no direct Internet access? (Or am I the last remaining one?)

Thanks,

-Paul

[LTinker68]

Email support or call them (or your sales person) -- they'll email you the link.

[paul55]

Will do, thanks! One thing I noticed while poking around with Process Explorer while holding down an arrow key in Flare, is that even with GDI+ rendering shut off, I still see gdiplus.dll in the main thread stack trace sometimes. I'm not sure if that's significant or not, just thought I'd mention it.

Another interesting thing is that scrolling with the mouse wheel through my document is *not* slow at all -- it's just as responsive as other apps on my machine (e.g. Visual Studio), and the CPU only hits 18-20% while wheeling through text pretty fast. So it's not a screen rendering problem per se.

Holding the arrow keys down is a different story -- that's where it gets really slow and uses 55-60% of the CPU. Something's definitely going on when you move through text... as if it's recomposing the whole page layout on every keystroke, although it doesn't seem to be updating anything on the screen except the caret position.

-Paul

[paul55]

A few more data points on this:

* Arrowing through text -- slow, uses 55-60% of my dual-core CPU;

* Mouse-wheeling through text -- fast, uses 18-20% CPU;

* Dragging the mouse around to select a range of text -- slow, uses 55-60% CPU, same as arrowing through text;

* Scrolling through a document rapidly with the scrollbar -- draws pretty quickly, uses 35-40% CPU;

* Selecting text with Shift+Arrow or Ctrl+Shift+Arrow -- slow, uses 55-60% CPU.

So at the risk of repeating myself... the high CPU usage has something to do with changing the cursor/caret location, not with drawing on the screen per se.

-Paul

[samjones6]

I have also found the Flare editor to be resource intensive and slow and sluggish.

[LTinker68]

So at the risk of repeating myself... the high CPU usage has something to do with changing the cursor/caret location, not with drawing on the screen per se.

That's really good information. Make sure you mention that to MadCap Support.

[Andrew]

A few more data points on this:

* Arrowing through text -- slow, uses 55-60% of my dual-core CPU;

* Mouse-wheeling through text -- fast, uses 18-20% CPU;

* Dragging the mouse around to select a range of text -- slow, uses 55-60% CPU, same as arrowing through text;

* Scrolling through a document rapidly with the scrollbar -- draws pretty quickly, uses 35-40% CPU;

* Selecting text with Shift+Arrow or Ctrl+Shift+Arrow -- slow, uses 55-60% CPU.

So at the risk of repeating myself... the high CPU usage has something to do with changing the cursor/caret location, not with drawing on the screen per se.

-Paul

If I had to guess, I'd say it has to do with how Flare needs to deal with all the XML parsing and such. For normal scrolling, it's just the normal real-time transforms / rendering that Flare does, so it's pretty fast. When you select text or arrow-key through, Flare has to actually parse your "point of entry" cursor through a lot of the XML as you move from node to node, rather than simply transform and display. But I'm speculating.

[paul55]

That's really good information. Make sure you mention that to MadCap Support.

Well... I wasn't really going to bother opening a case at this point, since it's not a big problem for me. On the other hand, if other people are having the same problem, I could send this info in. Would I just file a bug report, or is there some other way to open a support case that would be better?

I have also found the Flare editor to be resource intensive and slow and sluggish.

From reading your other posts, I don't think I'm having nearly as bad a problem as you are... for me, things like Ctrl+G and pretty much all the other functions in Flare are reasonably fast; it's just anything that changes the caret position that seems to eat a bit of CPU. But it still responds more or less as fast as I can type, so I can still be productive with it. My project is still pretty small at this point, but I'll see if the slowness gets worse as I get more content added into it. In your case, it sounds like pretty much everything in Flare is unusably slow. It's not that bad for me (at least not yet...)

If I had to guess, I'd say it has to do with how Flare needs to deal with all the XML parsing and such

I think you're right; what I don't understand is, when scrolling, the text layout (theoretically) doesn't need to change. But when arrowing through text, the layout shouldn't need to change either, right? That's the part I don't get...

-Paul

[LTinker68]

But when arrowing through text, the layout shouldn't need to change either, right? That's the part I don't get...

No, but you're moving in and out of tags as you use the arrow keys, so that's the parsing he's talking about, whereas with scrolling you're not necessarily hitting the tags.

[RamonS]

That's really good information. Make sure you mention that to MadCap Support.

Well... I wasn't really going to bother opening a case at this point, since it's not a big problem for me. On the other hand, if other people are having the same problem, I could send this info in. Would I just file a bug report, or is there some other way to open a support case that would be better?

Yes, opening a bug report is the best way to go. Someone from support will grab the ticket.

If I had to guess, I'd say it has to do with how Flare needs to deal with all the XML parsing and such

I think you're right; what I don't understand is, when scrolling, the text layout (theoretically) doesn't need to change. But when arrowing through text, the layout shouldn't need to change either, right? That's the part I don't get...

Other things such as the context based menus change. There are these orange 'boxes' that when clicked on show a menu. Besides that, when starting to type the editor needs to figure out where to add the new content and which tags to add. Pressing Enter in a paragraph is doing something else than when inside a list.
I'm just guessing here that these decisions are made proactively rather than on key press / click.

[bayda57]

I am finding problems with CPU usage as well. After working for a while, when i open another topic, my CPU usage for Flare goes to 25% and freezes Flare for 3- 5 minutes.

I'm using Windows 7 Professional 64-bit SP1, Intel i5CPU 750 @2.67GHz, 8GB RAM.

David Blanchard

[Andrew]

I am finding problems with CPU usage as well. After working for a while, when i open another topic, my CPU usage for Flare goes to 25% and freezes Flare for 3- 5 minutes.

I'm using Windows 7 Professional 64-bit SP1, Intel i5CPU 750 @2.67GHz, 8GB RAM.

David Blanchard

Whoah, that is most *definitely* not normal.
1) Is your project on a network?
2) Does everything open very slowly at first as well, or does this issue occur only after "a while"?
3) Does this issue then occur *every* time you open a new topic?
4) Can you reproduce the issue using a blank test project?

[bayda57]

I've been been monitoring the memory on Task Manager as I've been working. Every time I carry out a function, the amount of memory (private working set) increases. When i opened Flare this morning, the memory was about 42,920kb. After working on reformatting pages (I'm converting a Robohelp project to flare) for about an hour, the memory is at 149,140 kb. Every time i carry out a function, the amount of memory climbs.

David

[Andrew]

I've been been monitoring the memory on Task Manager as I've been working. Every time I carry out a function, the amount of memory (private working set) increases. When i opened Flare this morning, the memory was about 42,920kb. After working on reformatting pages (I'm converting a Robohelp project to flare) for about an hour, the memory is at 149,140 kb. Every time i carry out a function, the amount of memory climbs.

David

That is fairly normal; 150MB is not much for Flare. My projects typically go up and down, but tend to be in the 80-300MB range. I doubt that has anything to do with the CPU usage issue. Interested in knowing your answers to my other questions.

[bayda57]

) Is your project on a network?

No

2) Does everything open very slowly at first as well, or does this issue occur only after "a while"?

It occurs typically about 2-3 hours starting.

3) Does this issue then occur *every* time you open a new topic?

Once it starts occurring, then it will happen ever second or third occurrence.

4) Can you reproduce the issue using a blank test project?

I haven't tried creating a new test project nor have i tried to see if this occurs if i converted a Framemaker project.

At the moment, I've only being converting my Robohelp projects, and it has occurred in all of them.



David

[Andrew]

Can you reproduce this problem on another system?

Have you tried to disable your virus scanner?

Also, if you have support with MadCap, I'd contact them about this.

(I've converted old RoboHelp X5 projects to Flare, and haven't had this problem. Can't speak of any other RH versions.)

[samjones6]

)At the moment, I've only being converting my Robohelp projects, and it has occurred in all of them.

You may want to look at sticking to Robohelp v9, if you can.

I am a former robohelp user, and have had TONS of problems like this with Flare.

Flare support failed to resolve the issues.

I have found Flare to be very painful to use and live with. The raw bug count is over the top (I have over 40 bugs open and reprod by Flare support).

[LTinker68]

)At the moment, I've only being converting my Robohelp projects, and it has occurred in all of them.

I am a former robohelp user, and have had TONS of problems like this with Flare.

Your mileage may vary as everyone's system is different and not everyone has had the problems that samjones6 has experienced. That's why we ask things like if you can recreate the experience in a test project or on a different computer, since an imported or converted project or a specific computer may have other issues that cause the problems. Although I think samjones6 indicate the problem was in test projects, too, and possibly other computers, but that may not be bayda57's experience, which may narrow down the problem that bayda57 is having.

[bayda57]

Hi Lisa,

I'm going to load Flare on my laptop. This weekend, when i have some time, i will try both creating a new project and converting an existing project to see if i am getting the same issues on that computer.

I am converting from RoboHelp 5x. I will try converting from Framemaker 8 next to see if that makes a difference.

David

[samjones6]

David,

You might also want to try the robohelp v9 demo.

My experience is that robohelp is much better in this regard than Flare.

[RamonS]

Worth a try, but given the many complaints about other issues with RH9 in the Adobe forums you are gaining a bit and loosing somewhere else.