Speed issues - v6 vs v7

I have recently translated a database solution from 6 to version 7 and have finally got the whole thing to work exactly the same as before but this time all the separate related files in one single file. However I have noticed that running in version 7 the whole database is significantly slower. Simple routines were faster on my old 400MHz G4 laptop in v6 than on my dual 2GHz G5 running version 7.

As a test to make sure it is not coding errors i ran a simple script that 'shows all records' (850) then places a '0' in a single field in each record. In version 6 this takes less than a second. In version 7 this takes over 9 seconds and even shows me a bar detailing progress on the replace.

the script is:

Go to Layout ["List Handicap Differential]

Show All Records

Replace Contents [No Dialog, "Record Number", "0"]

Am I missing something or does Version 7 have a major speed problem?

I have had no probelm with the speed of FMP 7. I have a 400Mhz computer acting as my "server" for FMP 7, and have not had any problems what so ever. In fact, I just wrote a script to format phone numbbers for 50,000 records and it was completed in a resonable amount of time.

-Matt

I think that many people have seen this kind of behavior...FM 7 "appears" to be slower, I think due to the new graphics engine. It takes a bit longer to refresh screens and pop dialogs than it used to...this give the appearance of a slower app, when in reality the data process is long done.

make sure you have the latest update v2 it think...it seems to solve some of the speed issues.

As an aside, I am NOT impressed by the speed of the dual processor systems. I have a Dual 1.25GHz G4 as well as a 900Mhz G3 iBook...I think that the iBook blows the G4 away in terms of speed. I used to work at and office where we had several dual G4 systems and they all appeared slow in response. I ended up bringing my iBook to work and used it.

So I think that maybe this is some of what you are experiencing.

maybe it has to do with processer capabilites... some are good graphics some are good for statistics and maths?

Yes, I am sure 7.0 is slower because I develop on Macs and PC's and it has been anywhere from 10X to 50x slower on both machines and it does not matter which processor I use. Pop-up lists and printing are extremely slow. I have been told to up the memory cache on the Windows machines and told to use pop-up windows to replace the pull down lists. - D

There is another posting recently which has addressed this ... it seems to be a mixed bag. I personally have had absolutely no problem with FM7. I just continue to be amazed with the difference in speed (faster). I have found my queries, printing and data entry to be much, much faster.

The kick is that I have an application that has a limited lifespan on Server 5.5. Until that applicaiton is done, I have 7.0 on a refurbished Pentium III 256MB system and it is still faster then my Pentium IV 512 MB system. I can't wait until I get to move 7.0 to that computer.

You might want to take a look at the cashe with 7.0. You can really increase the server cashe past 40MB, which is great.

"Pop-up lists and printing are extremely slow"

Ahhhh yes, there are known issues with the display of value lists, portals and rendering, and FMP 7 performance in these areas is often not up to FMP 6 standard. However, the new database engine in FMP 7 is significantly faster than FMP 6 for queries and other index-related operations.

So at the moment it's a mixed bag for FMP 7. However, it has the *potential* to blow FMP 6 out of the water.

I have databases ranging from a few dozen records to 900,000 records running on a Pentium 4 w/ 512 MB RAM and cache memory set to 64MB. While there are some advantages with FM7 and the larger files, there are definetly still some problems with FM7. Specifically layout development now has a definite lag between selecting something and being able to move it. I have also had a few strange crashes related to working on layouts that would suddenly close down the application. This is reproduceable with subsequent attempts to make the same change. The layout becomes corrupt. Speed is a mixed bag depending on size and type of query but I have not isolated it, but FM7, when it is slower, is significantly slower.

I have isolated the problem a little, its to do with the replace command. 900 records, numeric field called 'record number' with no references to it in any other calculations or fields. Indexing off. Made a layout with just that field on it to make sure this is not a graphic problem. Also increased memory cache to 40MG

Go to Layout ["Speedtest"]

Show All Records

Replace Contents [No Dialog, "Record Number", "0"]

In my main database which has over 100 fields per record this takes about 9 seconds to do this simple replace. If I create a new database with just this one field and do the same replace it takes on 1 second. My database has a lot of these replace calculations so this is a real problem for me.

Try making your layout View as Form and add a Freeze Window before running the Replace. Note that if you have any fields set to auto-enter with 'Do not replace existing value for field' deselected, these will be recalculated. If there are any summary or unstored calculation fields on your layout, these will be recalculated also.

I, too, have problems with FP7....a download I do takes 45 minutes on FP5 & 6 now takes 7 hours....no joke!!! I have taken out all references to indexing, increased the cache and am on the verge of buying a new computer....my computer tech says I have one of the fastest, and am only using 1/3 the memory. We're updating to FP7.3 today -- but any other ideas would be appreciated.....

thanks

Yep, I agree.

I've been using FM7 Developer now for two days and I'm definitely finding it much less snappy than FM 6.

The pop-up list performance is horrific.

Funny thing is though, if you change it to a pop-up menu, it's instantaneous.

In general I think FM7 is a big step forward in terms of having tables, etc, but until slow popups are fixed (and anything else I'm not yet aware of), there's no way I'd deploy it to our users.

I also wish they implemented a duplicate table function. It's a real pain to re-key the same large table and I don't think we should have to pay extra for a pluggin to do this. I've found a quicker way to do it, by making SQL Create Table calls using ODBC which generates then in a flash, but it doesn't allow you to re-create calculation fields on the fly.

Anyway, enough rambling.

Cheers, Nick

The system I'm working on is a P4 2.8, 1gb memory. FM Developer 7.0v3

I haven't even gotten to the pop-up tables yet. And I find having tables in each and every file I use a big waste of computer space. I have 3 tables that the same information applies to 5 different reports. And to have all the data for all the reports in one file would mean I have a file that could cover the state of Alaska!!!

We're trying to download FP7.03 -- says 6 hours...and seems to be THAT slow...will do that download tonight!! sigh

About making the tables....I did find that I could import the data to the table very easily. My data was exported from the old Filemaker 6 version to an Excel spreadsheet and then imported into FP7. I had to create the definition fields, but that was easy to do compared to typing in 790 records. It took only seconds to do this.

hope this helps you.

We've noticed that tables with many globals are very slow to open the first time you access a record in that table (e.g. table with 100K records).

Anyone else having issues with globals?

I had the same issue. If you look under FileDefineFile References open any linked databases listed and delete the file paths. Then Select the add path and point it to the database it is linked to. In some cases I had up to 7 or 8 paths that were listed and some of those paths were to locations that didn't even exist. When I started it was taking about 1 min 45 sec. to get the database up from when you login. After I made the changes it took about 4 sec. Hopefully this will help some one.

I believe I found my problem....one of the formulas that was converted from 6 to 7 changed and said "auto entry" AND Look up --- I don't think it could do both and rather than giving an error message, it just slowed waaaaaaaay down. It ran fine after I fixed that.

Thanks to all for your information.

I am re-building in FMD7 from scratch, an existing FMP6 solution that imports a large (53Mb) text file and parses it, via 12 calculated fields, with some of the calculations relying on other calculations.

It used to take 5 hours to import with FMP6, with indexes on.

However with FMD7, with all indexing off, 24 hours later it still had 6 Mb left to go, and had dropped from ~8000 bytes/second to ~200 bytes/second. Disgusted, I killed the job, and am now pre-processing the text file using MS Access, which imports & parses it in about 5 minutes.

So how do I justify to the budget-controlling techno-weenies why I need to use a "non-standard" product like FMP7, when I need Access, anyway & is so much faster? Remember, their eyes glaze over after 20 seconds...

I am upgraded to latest FMD7 patch... is there a patch or a workaround?

This is a known issue with FMP 7. Make sure you are using FMP 7.0v3, it was meant to improve it.

Yea, I think it does infact!

Thanks for the tip!

I downloaded the patch and it DID fix it!

Yee-hah!

We've noticed that tables with many globals are very slow to open the first time you access a record in that table (e.g. table with 100K records).

Here is an issue of not taking the shift of paradigmas in oath. Plastering your solution with globals is past tence and should be altered to script parameters instead where it's posible ...which however not might be the problem in your case??? It's common sence in C++ programming or at least a raised eyebrows issue from your tutor.

--sd

Thanks for the suggestions they do make sense.

This problem refers to a simple replace command and that it takes about 6-9 secs to replace a field in 1000 records. This is not to do with layouts as I have put a blank layout together with just the single test field on it. This field is not used by any other calculations. In a test database with only this one field in 1000 records the replace takes less than a second. In my working database with about a hundred fields per record this same test take 6-9 secs even with layout that only has this one field that is not referenced by anything in the database and with the layout set to form view so it does not have to display a list of all fields.

My script is very simple:

Go to Layout ["Test Speed"]

Show All Records

Replace Contents [No Dialog, "Test Field", "0"]

This is driving me nuts as many of my calculations require replace commands. In version 6 this was instant.

Thanks for your help.

Try adding a Freeze Window step before the Replace, just for the heck of it.

In regards to Globals. I have a DB that I call a "Parse Script" This database imports a credit report web page, HTML and all, and Parses out the data that I want.

In FM6 I had one that didn't import the HTML, I copied the text, and extracted the data that way. FM7 allowed for More than 64000K, so wanted to make it cleaner.

In FM6, I could parse even the largest page in a matter of 2 or 3 seconds, MAX.

With FM7, It took over 30 min to do 70 credit reports.

To do this, most of the data transferes through Global fields. The process of getting a section of a credit report in to a global field so that it can be processed, takes as long as parsing the entire report did in 6.

Any suggestions for this type of application?

Is it possible that using a seperate table with a constant would work faster than a global field?

Thanks.

My God, what have they done! We just upgraded our v5 business management system with a server with 23 databases and 10 users. NIGHTMARE. 7 is so slow it is going to kill us. And the ******* pop up menu's take 5 seconds to load. I am calling tomorrow to completly flip out on them. How can you release a product this bad to market?

You may not have done all that you should to clean up your existing files before and after conversion. Most people have noticed performance improvements in several areas. There are some key issues that, when not addressed, can cause very slow speeds. This thread addresses some of those. If you can narrow down your performance problems, see if it is addressed in this or other threads, or check if it's addressed in the Migration tech briefs on FileMaker's website.

I had the same issue. If you look under FileDefineFile References open any linked databases listed and delete the file paths. Then Select the add path and point it to the database it is linked to. In some cases I had up to 7 or 8 paths that were listed and some of those paths were to locations that didn't even exist. When I started it was taking about 1 min 45 sec. to get the database up from when you login. After I made the changes it took about 4 sec. Hopefully this will help some one.

YAY! Thank you! I had the same problem and after I went through and deleted all the wrong paths my databases started flyin. Now they open almost instantaneous. My databases were converted from v5 and there were some paths to files that didnt even exist. In one instance a file was referenced 6 times!

Greetings - Additional Information.

We have found several ways to improve the performance.

1) Check your settings on the server. Increase cache memory and the time between cache flushes. Check you number of users and number of files and decrease as appropiate.

2) Check your settings on all the clients. Increase cache memory and change the setting from flushing when idle to a flush time. We are using 10 minutes.

While the drop down issue is still somewhat bad it has been improved. So have the "redraw" of the screens in the GUI system.

Additionally, even though we have twice (512MB) the amount of recomended memory for our level of usage on the server (256MB) we found out that when doing a backup (we have them scheduled every two hours) there is only 4M left. And the page file is trashing to no end. Since we have only one 512MB stick on the server we are adding three more in the future for a total of 2GB memory on the server. We will see if this additional memory improves the situation.

Hope This Helps.

I believe I found my problem....one of the formulas that was converted from 6 to 7 changed and said "auto entry" AND Look up

There is a known issue -- well, known to some people, anyway -- with autoentered lookups causing very big slowdowns. A project manager of mine just came back from a developers conference and told us for the time being to change every single "lookup" field in our solutions to use autoentered calculations instead, with the calc set to always overwrite existing data, until FMI issues an update.

Mike

I've been working with FMPro for years so most of the stuff was already changed. The references are all correct, btw reference by IP seems to yield a slight improvement over by name, the server is set to 256mb cache and has 1gb. The clients are set to 64 mb (all tables total around 128 mb), I am going to muck around with the cache flushing time. The biggest problem by far is the pop up lists. If there is only a few items and it is a local list, it is not too bad, but if it is a reference to a field in another file with a relationship that requires a select of a portion, it can take up to 15 seconds to load. That is simply unacceptable.

Greetings -

We have also found out that speed is affected by the number of files you have open. The less files you open when your solution comes up, the speedier your application will run.

I'm pretty sure FMI is working on a fix for the slow popup menus since they have a techinfo article talking about the issue. They suggest using popup menus if possible. I've found that they are alot faster.

Greetings Reed - Thank you for your posting.

You are correct. We have changed all the ones that are a small list. On the larger ones our users preferred to still have the drop downs.

Greetings -

256MB is the recomended amount of memory for our usage.

At 512MB the backup took 22 minutes to complete and we basically got lots of coffee cups.

At 2GB (we added some memory) the backup took 2 minutes to complete and we do not even notice.

Welcome to the ---real--- world.

Hope That Helps.

Add me to the SLOOOOW list. FMP6/WebCompanion/CDML 500 records, search, sort, calculate = 13 seconds to completion (finalized in graphic applet).

Just converted the whole mess to FMP7 SA, using Lasso 8 and inline commands, 500 records, search, sort, calculate = 53 seconds to completion (finalized in graphic applet). This is unacceptable, disgusting and pathetic.

This is a web-enabled example.

How can you change the amount of memory?

on a windows server 2003?

This is the solution i need!

Greetings -

256MB is the recomended amount of memory for our usage.

At 512MB the backup took 22 minutes to complete and we basically got lots of coffee cups.

At 2GB (we added some memory) the backup took 2 minutes to complete and we do not even notice.

Welcome to the ---real--- world.

Hope That Helps.

Greetings -

We had 1 memory stick of 512MB installed on the computer. We bought 3 additional 512MB memory sticks and installed them.

In other words we upgraded the hardware.

Hope That Helps.

We are going from v5 to v7 and I am noticing some problems with speed. We have a layout with 5 portals on it and in v5 the screen refreshed immediatly as you browsed records. It now flickers and pauses for a second before all the portals are displayed, which basically means you can not quickly click through the records one by one.

I have a feeling the boss will shoot me if after spending

Greetings -

If you have not already done so, please read all the way from the beginning of the thread.

Portals and dropdown lists are a real problem (in this and other forums) and someone posted here that the Filemaker folks are looking for a solution.

Calculated fields and Summary fields are sometimes giving problems and in the case of summary fields are dog slow (this was reported and discussed at length in another forum).

In this thread, there are a whole bunch of items that can help some with the speed problems, but they hit or miss, eventually there has got to be a solution posted by the FM folks.

Make sure you have updated the client to V3 and the server to v2. Some individuals in this thread have reported fixing of the problems. Clean up your file references.

But if something helps or not is very specific to each site.

Here are the links to the other forums:

http://talk.markjeffords.com/fmtalk/topic.asp?TOPIC_ID=1121

http://talk.markjeffords.com/fmtalk/topic.asp?TOPIC_ID=1112

Please note that it might me usefull to look at other threads in those forums besided the one that I have posted above.

Hope That Helps

Here;s my unsolicited advice:

To me it never made sense to "upgrade" your solution by converting it from an older version.

Instead, go the painstaking route of building it from the ground up in v7, learning as you go. Then, import the data.

You'll end up with a "pure" v7 solution and avoid many of the pitfalls that are inherrent, but not apparent in converting from a previous version.

I've done this on several large enterprise solutions. It took several months of hard work, but that pales in comparison to the time and energy I spent trying to fix converted solutions - that I ended up giving up on.

It's a bummer that you can't run Server 5.5 and Server 7 on the same machine. This is the only reason I can see to being "forced" to convert a v5 or v6 solution. However, if resources permit, I'd still advocate stricking with the orignally designed version - even to the point of running another server for the other version. (I run both versions in one of my larger environments, one runs Server 5.5 the other v7).

Greetings Bruce -

I appreciate the feedback. But I did not have the choice. 70+ files, 350+ layouts, 80+ customer data pulls. Those customer data pulls are scheduled through the month (some every week) and billing is based on the production work. We track a complete industry and have a whole department that feeds the database. I get the data out to our customers.

I had to come in on a weekend and do the conversions. The clean-up the problems over the following weeks. This happened while the solution was live and production work continued.

The solution is working properly now since several production cycles have been done. A bit slow in some drop downs, and some re-work of some calculated fields. We optimized everything that we could. Data pulls are taking about the same time, or less. Not too bad considering everything. We could be happier, but that will happen as the FM7 folks work out some of the speed problems.

You ---gave up--- on your conversion. I ---completed--- my conversion. And I got mine working. And the time that it took me to solve the problems (on and off for about two weeks or so) were a lot less that reworking the solution for several months.

I posted as I solved the problems so others would not have to go through what I did.

As I get a change I will re-work into a new FM7 application. In the meantime we are still very profitable.

Robert -

Glad to hear you got 'er up and running better after your conversion.

My solution was just about as hefty as yours was (about 45 files, 100's of scripts and layouts) - It had been years since I built it and couldn't get my mind around it again to clean it up. You're much braver than I

The opportunity to build it from scratch gave me achance to correct some of the inherrent design flaws that I'd been working around for so many years.

I've been thrilled with the results and now take full advantage of v7s features. Many of which I had wirked around in v6. The best part is, I'm slightly wiser for all the blood sweat and tears taht went into this endeavor.

I hate to beat a dead horse here, but a frustration I'm having (beyond those already stated) when working on a layout is that simply clicking anywhere on the layout - on a field, label or even a blank space - causes FMD7v3 to pause for a brief moment. Just clicking causes it to pause - not evening trying to move a field or anything, and while a 'brief moment' might not sound like a big deal, when you're used to moving quickly and freely on layout design, it becomes maddening.

Per suggestion, I've upped the cache to 64MB and set the cache to save every 10min. I'm working on a P4 laptop with 512MB RAM, Win2K Pro SP4, and while this machine may not be the fastest screamer on the block, I never had this frustration -- or anything even close to it -- with FMv6.

I'm really just now sitting down to learn FM7 by re-building a solution from scratch, and I won't say I'm hugely disappointed with the new software, but I will say if FM doesn't get some of these issues ironed out soon it's going to drive me crazy. Building layouts has always been one of my favorites activities with FileMaker (all the way back to pre-Pro FileMaker), but now it's so painful it's beginning to turn me off of wanting to learn the new software at all.

-Gosub/Stever

When I first inastalled v7, I got the same irritating lag. It wasn't much, just really frustrating if you're going to spend 10 hours a day working with it.

After w ashort while, I couldn't stand to work with it - especially in layout mode where moving objects around was "sticky".

This experience was consistent across many machines working with local files - Windoze XP, Windoze 2000, and OSX. However, I can't honestly say that I recall the moment things snapped into place and the issue was resolved, but I do know that I updated to the latest patch, defragmaneted the HDs and somehow the stickyness went away. Like I said, I can't recall the thing I did - just that now it's working fine.

My gut tells me it had to do with the update, but if that was the case, your issue woudl be fixed. I'd try a few off the wall things like defragmenting, chaing the monitors refresh rate, reinstall/update the video driver, etc.

I hear your pain - I can't work with the laggy, sticky applications either.

I've seen this layout mode slowness as well, but only on my lowest-end windows box (a PII 400). This has persisted through all the updates on this machine. No problems like this on the other machines (G3 400, 500; G4 533, 1000; G5 1800; P3 733; P4 1500, 1600, 2000) The only thing I can think in my case is the PII video uses shared memory....

The layout mode stickiness went away for me when I installed a higher-end video card. It was really annoying and couldn't stand it anymore so I upgraded. Just another cost of doing business I guess.

I think that many people have seen this kind of behavior...FM 7 "appears" to be slower, I think due to the new graphics engine.

Im wondering if "the new Graphics engine" was a pre war design.

Such a shame to handicap what could be a superb product...

-- wishing I did not make the decision to upgrade our server and stations --