Flare 4 slower than Flare 3.1

[Gary Niemen]

I'd be really grateful to get some more tips here - basically, we can't use Flare 4 until we have sorted this out. The information I have given already points to something in Flare 4 rather than our computer set up.

[Richard Ferrell]

Can you open a support Ticket for this issue, we would like to see your project.

https://www.madcapsoftware.com/support/contact.aspx

[forfear]

i posted a bug item on this...though i think i mentioned to support that I'll monitor this thing...
Leave Flare 4 open your desktop and leave your computer idle. Return an hour or so later the windows page file shrinks over time...that's why you notice the slowdown in the XML Editor. all your tasks slow down. I thought maybe active directory might have something to do with it since we are doing some internal updates to the servers recently.

[KevinDAmery]

Leave Flare 4 open your desktop and leave your computer idle. Return an hour or so later the windows page file shrinks over time...

My recommendation to anyone who runs Windows (with or without Flare) is to use a static page file rather than letting Windows determine the size on its own. The exact size varies depending on how much ram you need (I usually use a number equal to my installed ram, but a case can be made for making it larger than that). The way you do this is go into the page file size dialog and set the Start and Max sizes to the same number.

The idea is that this way Windows isn't constantly adding and removing page file sections - once the page file is defined, it retains the same blocks of disk. As a result, the page file doesn't contribute to disk fragmentation. For even better results, remove the page file if possible (or set it to 2 mb if Windows won't let you remove it), run a disk defragmentation, then create the page file in the size you want. Usually this will result in one contiguous block of disk being used for the page file.

[RamonS]

And as defrag utility don't use the garbage tool that Windows comes with, use one that is smarter. I can recommend JKDefrag. It is freeware and makes use of the Windows API the same way as the standard defrag does, it just makes smarter decisions and better work.

[Andrew]

Leave Flare 4 open your desktop and leave your computer idle. Return an hour or so later the windows page file shrinks over time...

My recommendation to anyone who runs Windows (with or without Flare) is to use a static page file rather than letting Windows determine the size on its own. The exact size varies depending on how much ram you need (I usually use a number equal to my installed ram, but a case can be made for making it larger than that). The way you do this is go into the page file size dialog and set the Start and Max sizes to the same number.

The idea is that this way Windows isn't constantly adding and removing page file sections - once the page file is defined, it retains the same blocks of disk. As a result, the page file doesn't contribute to disk fragmentation. For even better results, remove the page file if possible (or set it to 2 mb if Windows won't let you remove it), run a disk defragmentation, then create the page file in the size you want. Usually this will result in one contiguous block of disk being used for the page file.

This is a fairly common computer myth. See this article on Virtual Memory in Windows XP, starting with "How Big Should the Page File Be?" Basically, unless you have some kind of special circumstance, for the most part you should let your OS manage your page file (though setting a lower bound is a good idea). The only common exceptions to that are if you use something like Fast-User Switching in Windows, or if you have multiple hard drives and you want to take advantage of the least-used drive for your page file.

[Telemarker]

I am running Intel(R) Core(TM)2 Duo CPU
T7500 @ 2.20 GHz
2.19 GHz, 3.50 GB of RAM
This should easily be enough - but Flare 4 is too slow for me to use. It hesitates every 3rd click. Flare 3.1 is fine.
There must be more to this issue. I don't understand.
By the way, I am running Windows XP Professional 2002 with SP3.

I'm dead meat...
My machine is as follows:
Pentium 1.7GHz
1Gb of RAM
10Gb free disk space.
I have had to go back to using 3.1 to get any work done, even after disabling all analyzing jobs/processes.

Can we expect a usable version of Flare4 for mere mortals soon?

[KevinDAmery]

Interesting points, but he doesn't say anything in there that convinces me he's right (just calling them myths off the top isn't enough - some sort of evidence would have been helpful....)

[Var]

Hi everyone,

If you are having this slowness issue please open a bug report with support. We need projects that exhibit this behavior, so we can reproduce these issues in house and hopefully find a solution.

Please use this form https://www.madcapsoftware.com/bugs/submit.aspx to submit these issues to us.

Thanks for your help,
Var

[Telemarker]

Hi everyone,

If you are having this slowness issue please open a bug report with support. We need projects that exhibit this behavior, so we can reproduce these issues in house and hopefully find a solution.

Please use this form https://www.madcapsoftware.com/bugs/submit.aspx to submit these issues to us.

Thanks for your help,
Var

Done!
Good luck with finding the issue... If you need a project to test I have a few, no, make that all of them...

[Gary Niemen]

I have now also submitted a bug report.

[RamonS]

I experimented with profilers and the one that works best appears to be AQTime 5 from Automated QA. They offer a 30 day trial. AQTime 5 can profile .NET applications like Flare at runtime. I found it easy to set up the project and run it, but it really drags performance down as it needs to do all the checking and logging. So running a profile on a compile of a project that compiles in 30 minutes under regular conditions is probably better done over the weekend or on a test system that shows the same behaviour. The profile logs may give a clue in which module the longest holdup is. It then still needs developers to do the profiling with that Flare project for that module, but least they know where they need to look.

[forfear]

dunno what profiler is...but it sounds pretty cool.i am going to go browse around and found out what that is....
none the less ppl..the more the merrier

http://www.madcapsoftware.com/bugs/submit.aspx

[help_dude]

I've experienced slow navigation/selecting with keyboard and the mouse and any typing. When typing and selecting, it takes between 1-3 seconds for a response.
I'm using the following: Windows XP Professional Version 2002 SP3, Dell PC, Intel Pentium 4 2.8GHz, 2.0GB RAM, 40GB hard drive with 6GB free space (16% free space).
I work off the main C: drive, don't use Source Control, single user of the project, defrag and clean temp files often, and use no real-time protection.

I have IntelliSense turned off and tested the slowness with only Flare 4.0 running, even different size Flare projects and topics--all the same slowness. With one exception, however, when I create a new topic it works normal. Once I start adding just plain text to that new topic, you quickly see the slowness again (more the content, the slower it gets).

Tech Support confirmed it's a bug (bug# 23549) on 9/18/2008. They were able to duplicate it with one of my projects I sent them.

The scanning Flare does after editing/saving a topic is really annoying. If I happen to click build primary at the moment a scan starts, Flare locks up for about a minute. I then have to wait for the scan to end. There should be a way to turn this off. Why can't the user control when it scans?

This problem is more than just an annoyance, it really affects work flow and productivity.
Please tell me there is a workaround for this? Is going back to v.3.1 the only solution?
Can someone from Flare please confirm at least that a patch is on its way, like really soon?!

Despite all of the praise that I've given Flare 4.0, I simply can't use it until this problem is resolved.

[RamonS]

dunno what profiler is...but it sounds pretty cool.i am going to go browse around and found out what that is....
none the less ppl..the more the merrier

http://www.madcapsoftware.com/bugs/submit.aspx

A profiler is either one of those who appear in TV police series or in regards to software it is a tool that measures general performance, resource use, or other uses typically in regards to amounts used or time needed. In this case a performance profile is likely the best as some encounter performance issues. The profiler will hook into all the .NET modules that come with Flare and measure the time needed to execute the code in these modules based on the current actions. That way hidden errors, long execution times, and so on can be detected. That helps narrowing the area of the delay or bottleneck, but it doesn't state "fix this in the line 538 of module ABC and things will be faster". That is still the task of the developers. But if they have several profiler logs the all indicate that module ABC takes excessively long it is the best start to step through that module and identify deficiencies.
This is also often done with SQL databases in order to find queries that take very long to execute. That way these queries can be optimized increasing overall performance.

[forfear]

dunno what profiler is...but it sounds pretty cool.i am going to go browse around and found out what that is....
none the less ppl..the more the merrier

http://www.madcapsoftware.com/bugs/submit.aspx

A profiler is either one of those who appear in TV police series or in regards to software it is a tool that measures general performance, resource use, or other uses typically in regards to amounts used or time needed. In this case a performance profile is likely the best as some encounter performance issues. The profiler will hook into all the .NET modules that come with Flare and measure the time needed to execute the code in these modules based on the current actions. That way hidden errors, long execution times, and so on can be detected. ....

How well put! haha ..thanks mr Ramon

[Gary Niemen]

I've experienced slow navigation/selecting with keyboard and the mouse and any typing. When typing and selecting, it takes between 1-3 seconds for a response.
I'm using the following: Windows XP Professional Version 2002 SP3, Dell PC, Intel Pentium 4 2.8GHz, 2.0GB RAM, 40GB hard drive with 6GB free space (16% free space).
I work off the main C: drive, don't use Source Control, single user of the project, defrag and clean temp files often, and use no real-time protection.

I have IntelliSense turned off and tested the slowness with only Flare 4.0 running, even different size Flare projects and topics--all the same slowness. With one exception, however, when I create a new topic it works normal. Once I start adding just plain text to that new topic, you quickly see the slowness again (more the content, the slower it gets).

Tech Support confirmed it's a bug (bug# 23549) on 9/18/2008. They were able to duplicate it with one of my projects I sent them.

The scanning Flare does after editing/saving a topic is really annoying. If I happen to click build primary at the moment a scan starts, Flare locks up for about a minute. I then have to wait for the scan to end. There should be a way to turn this off. Why can't the user control when it scans?

This problem is more than just an annoyance, it really affects work flow and productivity.
Please tell me there is a workaround for this? Is going back to v.3.1 the only solution?
Can someone from Flare please confirm at least that a patch is on its way, like really soon?!

Despite all of the praise that I've given Flare 4.0, I simply can't use it until this problem is resolved.

Agree completely.

[RamonS]

Good thing is that the MadCappers can recreate it and with the various projects that they now have available it should be easier to zero in which section of Flare is the main cause for the slowdown. Source code profilers allow for very granular measurements down to execution time of each line of code. With that it should be easier to pinpoint exactly what causes the problem.
The tricky task is to fix that, which may not as easy as it may look like. Where I work we encounter these issues from time to time and it is often difficult to decide which way to take. Speeding one thing up may cause others to be slower. Or it requires a redesign of entire portions of the software, which then may cause that parts need to be redone that were not originally affected. And then all of that needs to be tested.
Some may wonder why they didn't do it right the first time around. My guess is that projects can now be so complex and come in so many different variations and configurations that fully testing them all is impossible to do in a reasonable time frame. That means chances are that very specific constellations were not covered originally and things slipped through the cracks. Now that these are known I guess that going forward these constellations are part of the test plans for future releases.
I am not affected by this bug, but I still recommend to give the MadCappers a chance to fix it. Given the response times from the past I'd be surprised if there isn't something coming our way soon. Believe me, especially the QA people are awake each night banging their had against (cubicle) walls wondering why they missed that and how to prevent this from happening again. Bugs like this one are often difficult to prevent, so the focus must be how to deal with them.

[Richard Ferrell]

We are still looking for more projects if you are seeing it being slow in the editor open a support ticket.

https://www.madcapsoftware.com/support/contact.aspx

[bbuchko]

I'm probably a little fish swimming in a huge pond here, but I've noticed that, since Flare doesn't automatically close topics and maintains open topics in a project even if you close and re-open it, I can easily find myself with a whole lot of topics open at once. For whatever reason, these open topics seem to affect my response time.

If I do a Window->Close All Documents Except This One (which will take some time if you haven't done it for a while), I usually get back to speedy editing. That's probably a solution you've all tried, but I figure just in case...

[Gary Niemen]

Something else I could add that might help: I have both Flare 3.1 and Flare 4 installed at the same time. I also just looked and I have both .NET 2.0 SP1 and .NET 3.0 SP1 installed. Could two versions of Flare plus two versions of .NET be causing problems. One of our colleagues was getting speed issues with Flare 3.1 this morning - similar to the issues with Flare 4. We discovered that she had 4 .NET versions installed - 1.0, 2.0, 3.0, and 3.5. It just made me wonder. Any views?

[helen]

Something else I could add that might help: I have both Flare 3.1 and Flare 4 installed at the same time. I also just looked and I have both .NET 2.0 SP1 and .NET 3.0 SP1 installed. Could two versions of Flare plus two versions of .NET be causing problems. One of our colleagues was getting speed issues with Flare 3.1 this morning - similar to the issues with Flare 4. We discovered that she had 4 .NET versions installed - 1.0, 2.0, 3.0, and 3.5. It just made me wonder. Any views?

Well, if it helps, I too am running 3.1 & 4.0 and .NET 2.0 & .NET 3.0, and I'm not experiencing any speed issues with Flare 4 (it's faster than 3.1 for me).

[KevinDAmery]

If you don't want Flare to reload all your topics every time you launch the application, go into Tools > Options and disable the "Auto-Reload Documents" check box.

[LTinker68]

We discovered that she had 4 .NET versions installed - 1.0, 2.0, 3.0, and 3.5. It just made me wonder. Any views?

It shouldn't matter unless you run two different programs that access two different versions of .NET at the same time -- that might slow things down a bit, although I've had both Flare v3.1 and v4 running at the same time and didn't notice any speed problems. (Like Kevin, I don't have any speed issues with v4, even when I have six other applications running at the same time.)

Also, you have to be careful of what programs might be using what versions of .NET. For instance, if you delete .NET 2.0 then you can't use Flare v3.1 anymore but v3.1 will look for .NET 2.0, even though you have a more recent version installed. Likewise, we have programs we develop that were originally written for .NET 1.0 and haven't been updated to a newer version, so if I delete .NET 1.0 then those programs won't run.

[Telemarker]

(Like Kevin, I don't have any speed issues with v4, even when I have six other applications running at the same time.)

Cue Monty Python... You lucky, lucky, lucky...

http://www.intriguing.com/mp/_sounds/lb/lucky.wav