Are your search terms used in fields with unstored calculations? Unstored calc's can kill performance when searching - making the actual computer specs irrelevant.
Agreed with Stephen; there is only so much that hardware can solve if the design of the solution is the bottleneck. If your solution is not hosted and you only have it open on your machine then it should not take 5 mins to search through 500,000 records. That the design getting in the way.
Going with faster hardware may cut it down to 4 mins but not to 4 seconds.
Agreed with both replies, the hardware won't solve it. That said, Filemaker (especially if not server), is not memory intensive, and likes high Ghz CPU, so to answer first question go for the faster CPU.
An easy fix that may be possible is to break down your search, first do a search on the stored filed that may be used in you unstored field, and then constrain to the unstored field
Also the usual go to a blank form view layout, with a freeze can help
Yep, I've loads of work arounds, and it's usually like everyone here said bad design I guess. I've fields that are calculations of calculations and FM tells me that I can't index them. That said, even these fields with tons of text in them work just fine with one word searches. It's when I do a search like "more than one word" in speech marks it can take 10 mins to give me the result.
I do all the tricks to get around this the best I can, like narrow the search each time so start with more then constrain search with than then one then word etc. but sometimes you need to search for a phrase and this is the time killer.
I have basic layouts for these fields and that seems to help rather than searching off a layout with tonnes of portals on it.
i just wanted to know if upping the processor or ram is worth the extra 700 pounds it will cost and help me speed up FM.
You might do this.
Create placeholder fields and write data into them from the calcs then search on the indexable placeholders.
"To put our findings in perspective, the 6.4*10^18 instructions per second that human kind can carry out on its general-purpose computers in 2007 are in the same ballpark area as the maximum number of nerve impulses executed by one human brain per second,” they write. "Our total storage capacity is the same as an adult human’s DNA." ---Hilbert and Lopez (Quoted in the New Scientist)
Bear in mind that you'll only get at best a 20% gain, but it would be probably 10% speedup in real world
Whereas fixing your solution, would be order or magnitude faster so, if your low on money it's not really worth it.
I think you'll ultimately fix your solution, because minutes results are not sustainable. So maybe fix your solution first, and save the money (and maybe wait for next revision with kabylake which will give 10% more)
I had to read this reply several times. the use of "placeholder" threw me a bit. You meant standard fields (even if temporary), did you not? How are you writing the data to a field from a calculation?
Set Field ( temp1 ; calc1 ) // ?
if that is the case, then perhaps to optimize the data for indexes just take the step to Set Field rather than calculate?
oh and when I said blank layout, I meant really blank with no fields at all.
Put a button to enter search mode (or you can do custom menu), with a pause, upon resume, launch a script that : freeze window, goes to blank layout (in form view), perform the find, then gets back to oginal layout.
Also, if you have calcs of calcs, it's better to put all the calc in the one field you'll search. And make sure you use let statements in your calcs so you never reference the same fields several times.
So If you have Calc Field A and Calc Field B (the one you wan to search in)
Calc A : some complex A calcs
cal b : Cal A + some complex B calcs
Calc B : some complex A calcs + some complex B calcs
field A * Field A - Field A
Let(f=Field A; f*f-f)
You may actually be missing the component that is going to improve the performance the most on the new Mac Book and that is that the flash storage is now PCIe flash storage. In my experience, storage access (read/writes) is as important as the cpu and that both of these are more important than RAM assuming you have the minimum RAM required or more. 8 Gigs of RAM will doubtfully give you any measurable improvement over 16 Gigs. So as concluded above, go with the faster GHz processor and skimp on RAM. But realize that the PCIe storage is the component that will make performance on your new Mac Book so much faster than a 2010 model. In fact, it is likely that your 2010 model came with a spinning hard drive of 5400 rpm which is significantly slower than any flash memory, let alone PCIe flash storage. I bet your 5 minute searches will be under 30 seconds and maybe more. By the way, this advice about speed improvement by PCIe storage is for a file locally stored on your laptop and not a network accessed file.
Thanks Taylor, do you think that the basis specs of the MBP 13 will be enough for me. My FM db 14 is about 500K records, lots of portals, and runs okay with my mid 2010. It's just these searches that take a long time. Everything else is fine. MBP 13 specs below:
256 GB Storage
2.0GHz dual-core Intel Core i5 processor
Turbo Boost up to 3.1GHz
8GB 1866MHz memory
256GB PCIe-based SSD
1 of 1 people found this helpful
avoid 256 GB like plague. It's not enough nowadays, and it has zero resell value
Thanks Vincent, I could afford to just improve storage to 500GB+ if the other specs would be enough. Do you think such a machine would be able to handle my FM db with the rest of its specs
There is nothing wrong with 256GB of storage if you also get a 1TB or more external ThunderBolt drive when you need it. The base RAM is enough.
You may want to see how much the hyper threading of the i7 will really help you. If you need GHz for the money the 2.9 i5 with Touch Bar might be a better idea as it comes with faster RAM as well.
As mentioned, hardware alone will not fix your search issues. Have you tried ExecuteSQL to identify your results. You might be able to run the query on pre calc fields and speed up the process. Just depends on what you have going. I have done this with a DB that has about 1M records and the results come back in a few seconds.
Other options could be keeping what you have and getting a loaded Mac Mini to run FMS for cheaper than the laptop and use that to do the heavy lifting on the database and return only the results to your client machine. Anything that gets you into FMS is a good idea in my opinion.
Thanks Tom, for security etc I do most of my backups on external drives so 256 should be enough, but it's also cutting it fine.
The touch bar worries me. All the tear down reviews give it 1/10 for repair ability and I still haven't seen someone say how you will be able to force shutdown when the power button is on it. So I'd love to go for the touch bar 13 inch if I wasn't so concerned about how the tech is going to fair in its first major roll out. Maybe for my 2020 upgrade
I don't even know how to do ExecuteSQL, I will start looking into it. Is it something oyu can do on basic FM or just FM advanced?
What is FMS? I'm guessing FM server?