Is Filemaker Pro 7 much slower than version 6

[Andrew Wild]

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?

[matt d]

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

[Kurt Knippel]

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.

[Deep Thought II]

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

[dmadans]

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

[Computer Geek]

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.

[Vaughan]

"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.

[SpudMan]

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.

[Andrew Wild]

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.

[-Queue-]

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.

[dee1950]

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

[Blindfox]

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

[dee1950]

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.

[jkrier]

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?

[Gwave]

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.

[dee1950]

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.

[zincb]

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?

[Vaughan]

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

[Tissot]

Yea, I think it does infact!

Thanks for the tip!

[zincb]

I downloaded the patch and it DID fix it!

Yee-hah!

[Søren Dyhr]

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

[Andrew Wild]

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.

[-Queue-]

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

[Munchie]

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.

[Edward Newman]

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?

[Ender]

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.

[deego55]

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!

[Robert_Artigas]

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.

[ĸupiэȶƺ]

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

[Edward Newman]

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.

[Robert_Artigas]

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.

[Reed]

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.

[Robert_Artigas]

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.

[Robert_Artigas]

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.

[Xas]

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.