Um...for the Record...the UNDO...on the GM version of FM Pro is WAY WAY WAY faster that ETS or Pre Release builds of the product.
This clearly got cleaned up in the last couple of months...by FMI engineering!!!
So dump that pre-release and get the shipping version. I assume the localized versions are available now?
I dumped the prerelease before downloading the purchased version. I am now using the version I purchased and is still very slow.
I am also having speed problems. I converted 30 solutions from FM 11 and they are going outrageously slow. I have all new state of the art workstations and servers with plenty of RAM. I am also developing a solution that is native to FM 12 that is musch slower than it should be. What's going on??
Keep in mind that unlimited UnDo in layout mode requires the system recording each "Do" -- every tweak of an arrow key, etc.
Try doing a Save on the layout while working on it and see if it speeds up any from being able to dump the previous UnDo list. Just a hunch...
Are you running these 30 solutions on the converted servers? Did you dump the server logs when you installed? Did you reset the server cache or are you using the default?
Something is definitely wrong - FM12 is outrageously faster on my server and workstation. Don't give up!
Do you have ANY plugins installed? What specifically is slow in your solutions? scripts? navigation? startup? data entry? please provide more details so we can help you.
Thank you for your interest.
I am running about 10 solutions on FM 12 Server on a Windows Server 2008 on a brand new Dell (installed 2 months ago) see specs below.
PE R510 Chassis for Up to Eight Hot Swap Hard Drives, LCD
Intel® Xeon® E5620 2.4Ghz, 12M Cache, Turbo, HT, 1066MHz Max Mem
Intel® Xeon® E5620 2.4Ghz, 12M Cache, Turbo, HT, 1066MHz Max Mem
16GB Memory (2x8GB), 1333MHz Dual Rank LV RDIMMs 2 Processors, Optimized
Windows Server 2008 R2 SP1, Standard Edition, Includes 5 CALS
3x 600GB 15K RPM Serial-Attach SCSI 6Gbps 3.5in Hotplug Hard Drive
Hard Drive Configuration
RAID 5 for PERC6i/H700 Controllers, x8 Chassis
PERC H700 Integrated RAID Controller 512MB Cache
750 Watt Redundant Power Supply
I completely wiped out all traces of FM Server 11 before installing FM Server 12 and I set the cache to maximum allowed (8,185 MB). This server’s mission is solely to run FileMaker Server; however, I am experiencing very slow speeds even when I run the solutions on a workstation without sharing. I also increased the cache to maximum on all of our workstations and I have to note that my workstations are all fast, i7’s with plenty of RAM.
The only extension that I have plugged in is Troi; however, the slowness happens whether this is installed or not.
I want to clarify that I believe through trial and error that the slow-down has something to do with the graphics engine. My solutions have roots going back to FM 5 and I have always experienced relatively fast redraw times even with lots of imported graphics such as slick looking buttons and all kinds of icons to make the solution look great. When I converted these files to FM 12 the redraw time seemed to slow to as much as several seconds between field clicks or tab clicks. Scripts such as converting an invoice into a PDF now take about 10 minutes instead of about 10 seconds (not an exaggeration, we timed it). I started deleting every graphic element that was imported on the solution (fancy buttons and icons). I noticed an immediate increase in speed but still very slow compared to FM 11. Only after completely stripping down my solution of all the things that made it awesome did I get improvement in navigation speed.
Start-up speed – excellent
Data entry – delayed (1/2 second lag that is very annoying)
Scripts – slow to very slow
Navigation - slow
I have been working on a solution native in FM 12 that I started with the pre-release software. I am not using any imported graphics but I am using gradients and field rounding quite a bit. The navigation on this solution has a slight delay of ½ second to 1 second which is troubling. I also have noticed that script triggers and/or conditional formatting may cause significant slow-downs as well. I can provide you with a copy of any solution you would like if it helps you troubleshoot what is going wrong.
You pretty much describe my experience, all be it on a bigger scale.
The problem seems to be on the client side rather than server. The performance is terrible, especially on some of the older machines.
There is a long thread about FMP12 speed issues in the Forums here (http://forums.filemaker.com/posts/715ef37320), but my experience has been similar to KarendWeaver. Here is what I posted in the referenced thread:
Not sure why, but I simply haven't had any speed issues with either of the two FMP11 - to FMP12 databases that I've converted. I have 50,000 records in one database and I can scroll through them list view without any problem. In form view I can go from one record to another just as fast as in FMPA11. The other database relies mostly on portals and I haven't experienced a problem with it either.
This is so strange because usually things don't perform so well on my systems when they seem to go swimmingly for others. My iMac is four years old and nothing special. I haven't tested these databases on Windows, but I couldn't be more pleased by what I've seen so far on FMP12 on the Mac. Also I'm running them locally for the time being.
For what it is worth..
This is interesting in light of Dan's description and I too am on a Mac. I also have solutions going back to FM5, and I like graphics too.
I remember in past versions, there were many more problems with Windows than Macs in rendering graphics - mostly due to the graphics acceleration settings. I wonder if that is related to this problem? Dan - I assume you have already optimized graphics acceleration for previous versions of FMP?
The other thing I would look at is the age of the graphics you are using. If they are older (especially if you are using the same graphics you had in FM5) then I might try updating the graphics and see if that makes a difference. I had to toss some of my favorites and replace them when I went to Lion, because they were just too old. Also the file format may make a difference. Again, I have seen a lot of different file formats on Windows (and some Mac) solutions. I use only transparent pngs, and I size each graphic to the appropriate size BEFORE I put it in the database - never use the FM "resize" graphics option because it bloats the file.
Another option is to try placing the graphics in global container fields (you may be doing this already) - that also makes it easier to swap them out for testing.
I haven't had time to test this on Parallels yet myself, unfortunately I am totally swamped and barely have had time to do quick testing on FM12 - but I suspect I won't see much difference since I have my Parallels settings with graphics acceleration turned completely off, and I am obviously using the Mac graphics hardware.
I am definitely interested in the issue because my solutions also tend to be graphics heavy and I do deploy on Windows even though I do my development on Mac.
Dan, I'd be happy to test any of your solutions on my setup to see if there is a difference. That may help - but it may not. Let me know.
I have been following the communication threads on this topic in the developer forum. I have noticed some prominent names in the community that are experiencing speed problems. For now I recommend to people to NOT convert any files to FM 12 system wide before doing your own tests. I have been using FM since 1988 and I have confidence FM will solve the problems; however, they really should not have launched the product in this state. I made the mistake of converting everything over without testing because I have never had problems in the past.
I will attempt to adjust some graphics settings on my Windows 7 machines to see if it helps.
Thanks for the info, Dan, I have been following this in a few other threads also but all links are appreciated as this is a critical issue.
Yes the performance is terrible and it's not a server issue. I exported 20k records from a test database of name and addresses from 11 as a fp7 file then converted it and scrolled through it in table view on my Dual 3.0 GHZ Mac Pro with 6GB RAM and the scroll speed alone is 1/10 of what the file is in v11 running off the local drive in a side my side comparison. There are many problems with this release in myopinion that I won't mention here but the performance issues alone makes it a no go for any of my customers as far as I am concerned. If it ten time slower in table view on an exported file with NO interface at all it doesn't bode well for this release. I wouldn't hold my breath that is will get fixed any time soon they have had well over a year to do it while in beta and ETS mode and it's stilll not any better. Should be interesting to see what happens.
Although I don't deny that some specifics like scrolling through list views are slower, I've noticed nothing but tremendous speed increases in typical use.
In my case, I have FM Server 12 hosting a semi-large file (standard cable internet, Mac Mini) and I'm a client tapping in from another state (using wireless and basic cable internet). I haven't done a direct speed comparison between 11 and 12 yet, but there are a few items that are definitely faster:
"Show Index" is very fast, even the first time accessed. Type-ahead on an index is great, as well as getting to the last letter within a second of showing the index. Accordingly, dynamic pop-ups now offer the same new speed advantage.
Searches on unindexed fields are also very surprising. Found 1,000 rows of 165,000 when searching a text field (typically contains 5-10 words) in about 5 seconds. I used *zz* to make it more interesting. Searching on an unindexed number field for >1000 or <1000 was about 2 seconds. I don't think v11 had this kind of remote speed.
I'm quitting FileMaker and starting over for each test, but server seems to have cached just about everything. Some finds are becomming too fast to time, even if they are performed on related tables, unindexed fields.
I guess if your clients spend a lot of time scrolling through lists quickly, then this may be the primary issue right now -- although I'm really not seeing it unless I run a "scroll script" without "freeze". I'd say the overall performance is great, with the caveat that speed-reading clients should avoid fast list scrolling.
I'm going to convert a larger project (2+ million rows) laster this coming week and get out the stopwatch.