1 2 Previous Next 19 Replies Latest reply on May 11, 2017 1:30 AM by cmard2017

    What MacBook Pro specifications will be best for a big filemaker database

    cmard2017

      Hi I need to buy a new macbook pro and I want to get the 13 inch without touch bar.

       

      I can only afford to upgrade one specification and I want to know would it be better to go for 2.4GHz dual-core Intel Core i7 processor, Turbo Boost up to 3.4GHz or 16GB 1866MHz memory.

       

      I have a mid 2010 macbook pro at the moment on 4GB with 2.4 GHz Intel Core i5 and my FM database has about 500K records.

       

      When I search especially doing a keyword search with two terms in speech marks the search can take 5 mins.

       

      I want to get the upgraded specification that will give me the quickest searching/find speed for my FM database.

       

      I only really use my macbook pro for FM so this is the only concern, getting the best specification I can afford for FM to run better than it runs now.

       

      Thanks

        • 1. Re: What MacBook Pro specifications will be best for a big filemaker database
          StephenWonfor

          Are your search terms used in fields with unstored calculations?  Unstored calc's can kill performance when searching - making the actual computer specs irrelevant.


          Stephen

          • 2. Re: What MacBook Pro specifications will be best for a big filemaker database
            wimdecorte

            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.

            • 3. Re: What MacBook Pro specifications will be best for a big filemaker database
              Vincent_L

              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

              • 4. Re: What MacBook Pro specifications will be best for a big filemaker database
                cmard2017

                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.

                • 5. Re: What MacBook Pro specifications will be best for a big filemaker database
                  StephenWonfor

                  You might do this.

                   

                  Create placeholder fields and write data into them from the calcs then search on the indexable placeholders.

                   

                  Stephen

                   

                  -


                   

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

                  • 6. Re: What MacBook Pro specifications will be best for a big filemaker database
                    Vincent_L

                    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)

                    • 7. Re: What MacBook Pro specifications will be best for a big filemaker database
                      beverly

                      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?

                       

                      beverly

                      • 8. Re: What MacBook Pro specifications will be best for a big filemaker database
                        Vincent_L

                        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

                         

                        DO :

                        Calc B :  some complex A calcs + some complex B calcs

                         

                        don't do

                         

                        field A * Field A - Field A

                         

                        But

                         

                        Let(f=Field A; f*f-f)

                        • 9. Re: What MacBook Pro specifications will be best for a big filemaker database
                          taylorsharpe

                          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. 

                          • 10. Re: What MacBook Pro specifications will be best for a big filemaker database
                            cmard2017

                            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:

                            2.0GHz Processor

                            256 GB Storage

                            2.0GHz dual-core Intel Core i5 processor

                            Turbo Boost up to 3.1GHz

                            8GB 1866MHz memory

                            256GB PCIe-based SSD

                            • 11. Re: What MacBook Pro specifications will be best for a big filemaker database
                              Vincent_L

                              avoid 256 GB like plague. It's not enough nowadays, and it has zero resell value

                              1 of 1 people found this helpful
                              • 12. Re: What MacBook Pro specifications will be best for a big filemaker database
                                cmard2017

                                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

                                • 13. Re: What MacBook Pro specifications will be best for a big filemaker database
                                  bigtom

                                  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.

                                  • 14. Re: What MacBook Pro specifications will be best for a big filemaker database
                                    cmard2017

                                    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?

                                    1 2 Previous Next