Yet Another Performance Question

[Gordie]

I purchased FM7 a few months ago. While I had experimented with the trial versions over the last few years, I hadn't really done much with Filemaker since version 3 (whoa! a long time ago). I then convinced my primary client that he could use Filemaker Pro to manage some key (but simple) business data. Three tables, a few dozen fields, a handful of relationships, zero calculations, and away we go.

Unfortunately, as I have been developing the database, I am stunned by some of the performance issues. In particular, merely changing focus from one text field to another text field in Browse mode can be painful. Also I frequently type ahead of the software rather significantly (think Word 6 on a Mac Plus...).

The key speed issues you want to know...I'm using relatively slow machines - 466MHz G4 and a 400MHz G4. I have one field in the database that tends to have a fairly large amount of data - like 2-3 pages of a word processing document - not huge, but a decent amount. The database has about 10,000 records in it, but it will happen with a cloned database with only record as soon as I paste the word proc doc into a field. I do not have any of the spell check stuff on. I don't have any sharing turned on. The cache is at its default of 8MB. This is a really simple database, but the standard user interface elements just crawl along.

Is there anything I can do (other than buy a new machine...that will happen soon enough, but I don't want to force my client - using PCs - to have to upgrade), or is this just the way life is?

Thanks,

Gordie

[Ender]

Hi Gordie!

You should be able to run FM7 on those older machines.

Three things that I can think of to check:

1. Do you have 7.0v3 installed?

2. How much memory is on your test computers? (should have at least 192MB, over 256MB is better.)

3. Is your text smoothing set to turn off at 8 point or smaller? (FM7 needs text smoothing to display correctly. Check this in System Preferences->Appearance.)

Let us know.

[Leader]

Wow, what a problem.

If you're developing on a Mac and then transferring the files to PCs, have you actually checked the performance on PCs?

I wanted to ask if you're doing any heavy duty calc fields or formatting? Tht could conceivably slow down data entry, although not as severely as you suggest.

I found FM7 performed fine under XP, although I confess my machine is faster than what you describe. It's possible that once you make the transfer, the performace issues might go away.

[Gordie]

Ender,

I've got 768MB in my G4/466 machine and 256MB in the G4/400 machine (yes, a noticeable difference between the two). Both are running MacOS 10.2.8. I have font smoothing turned off at 9 pts and below (not sure from your post whether this is good or bad - I assume that font smoothing always has a performance hit). I am using FMPro 7.0v3.

My G4/466 machine is actually a pretty tricked out Beige G3 (bought the first day they were on sale back in 1997). I've milked it with a G4 CPU, lotsa RAM, USB, FireWire, a Radeon 7000 video card, and an Apple-branded DVD SuperDrive. However, my experience is that the machine generally performs pretty darn close to any other G4/466 machine in most respects, so I doubt that any of this is a factor.

I've watched the Process Viewer during some of these actions, and any editing action or changing of focus quickly eats up 65%+ of the CPU.

I can almost deal with an answer that says "buy a new Mac (or PC), and this problem will not exist." I'm just concerned that speeding things up by a factor of 3-4X is still slower than I would expect...

One last thought. Our plan is to host the database on a Mac Mini with a standard version of FMPro and share it to three users. Since the database was simple with very little coding/scripting and a pretty sparse user interface, I made no attempt to segregate the UI, logic, and data. Does anyone have any thoughts as to whether the performance would improve by sharing the database, and putting the UI only on the clients. Or, do you think that this is a UI performance issue (as opposed to a database design issue), and doing this will not solve the problem. Based on my experiment with one record vs. 10,000 records, I suspect that segregating the elements would create no significant improvement...

Thanks,

Gordie

[gdurniak]

Unfortunately, like most software, the FileMaker application got slower with each version, from 4 to 7, so you need to throw more hardware at it

FM7 is very sluggish on my 650mHz Thinkpad with Windows 2000. FM4 to 6 run fine.

[Ender]

Gordie, It may be your that Frankenstien computer doesn't have the system bus to handle the graphics needs of FM7. I have no problems with our oldest machines: iMac 350s with 192MB RAM.

Separating the UI would not make a difference in this case. That is mostly useful for WAN deployments.

The Mac Mini may work as a host (though the internal drive is not that fast.) I'd recommend getting the 512MB RAM and an external firewire drive so you can make backups on a secondary drive (unless you're disciplined enough to burn them to CD every day.) A G4 or G5 tower is be better if you can afford it.

[stanley]

Gordie:

I agree with Ender - the system bus on that old beige G3 is pretty slow, and that could be causing you some issues. I do my development work on a PowerBook G3/500, and I've got no problems with FMP7's speed, so I've got to wonder if there isn't a problem with your database.

Also, the Mac mini might not be the best server machine, mainly due to its hard drive, which is a 4200rpm laptop drive. That's not something I would want to trust as my server's primary storage unit, nor will it be able to deliver data as fast as, say an old G4 tower with a SCSI drive... That being said, the mini makes a great client machine.

Further, I'd recommend going to Panther, as it seems to speed up the older machines a fair amount, so long as they've got the RAM to handle it - my minimum recommendation is 512MB.

-Stanley

[Gordie]

All,

Thanks for the inputs. I'll try to explain a little more.

The shop is small (currently three people, including me - could go up to five at some point) and is in the recruiting business. I am using a Mac, and the other two are using PCs. Until I arrived, they had been using one of the PCs in a dual role as file server, and that has been a hassle and performance issue occasionally (mostly, the real problem is that this particular machine suffers from repeated plagues of spyware, etc.). I suggested they might want to consider a cheap Mac as a file server and database server. Of course, the Mac Mini sacrifices a lot of performance, but the company budget was small, and the Mini may end up on someone's desk in the future, so they wanted to dip their toe into the Mac pool carefully (and cheaply). Even as a file server, the Mini will be virtually never break a sweat. A 300k file saved three times per hour is considered rush hour traffic...

The database holds resumes, candidate info, client info, and job order info. There are no calculations, a handful of trivial scripts, and no fancy graphics. The relationships are few and of the obvious things like names and job IDs.

I suspect that bus throughput is not the first order problem. The types of things that cause slowdown (typing into a text field or changing focus) are just not bus-intensive - at least not for graphics. It is possible that the FMPro code is trying to do something behind the scenes that is churning CPU time and maxing out the bus to memory, but my UI actions alone should not be causing any database logic to execute. In word processors, this kind of behavior tends to be caused by doing lot of things like real-time spell- and grammar-checking and other activities during idle time (thus the Word 6 performance on a Mac Plus that I mentioned earlier). Not sure what FMPro might be doing during this time.

BTW, the team did not want to use the Filemaker Recruiter package because they felt it was overkill, and a simple, no-frills solution that is used is better than a slick, professional package that is not.

Soooo...the plan is to run the database on the Mini (obviously using a current version of the operating system - my development platform is stuck at 10.2.8). Then for a month, the PC folks will try using a trial version of FMPro as well as using Web browser access, and then decide which client they will use (probably the FMPro client). I just need to make sure that this thing isn't going to be a pig on relatively current hardware (Mac or PC). If so, we're back to just storing files and searching them somewhat haphazardly.

This is probably just another case of unintentional software bloat. I like the progress that FMPro has made in the last few years, but sometimes I think companies should consider having their developers write software on machines that are three years old or so, to provide real and continuous feedback when the software is slow...sorry, off topic.

Thanks,

Gordie

[Gordie]

I think I solved the performance issue...

I noticed that some records (in the same layout) had different performance - significantly different performance. I noticed that in one case, the font in the field holding the largest amount of text data was Courier New (a mono-spaced font). The text in the other was Geneva (a proportionally-spaced font). The record with the mono-spaced font was much snappier than the one using the proportionally-spaced font. I changed the Geneva record to Courier New, and Bam! performance picked up immediately. Scrolling was brisk, and changing focus from field to field was quick.

I have not done anywhere near enough experimentation to validate the theory that using a mono-spaced font will improve performance, but it's worth others looking into...

Anyone else seeing this situation?

Gordie