[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"$fsyxV-6rJaXsK6vx3k7sqSavGGTcn9W3WeswqPXrahuI":3},{"item":4},{"id":5,"idKnowledge":6,"idDomain":7,"idCluster":8,"kindOverride":9,"slug":10,"title":11,"description":12,"bodyMarkdown":13,"bodyHtml":14,"author":15,"date":16,"createdAt":17,"topics":18,"image":24,"hasDownload":25,"fileName":26,"youtubeId":27,"domainCrumb":28,"clusterCrumb":31},"375","F5A3F4E1-E62B-8B43-BAB2-92BE763CC770","E46BDB0A-2979-1E40-93F7-AC40185848A5","B11BED08-2F4E-4C45-9373-6175FA721411","article","how-to-find-slow-filemaker-scripts","How to find slow FileMaker scripts","A practical guide to diagnosing which FileMaker scripts are slowing down your solution, with step-by-step benchmarking methods and common root causes.","Your FileMaker solution used to feel snappy. Now a button click takes three seconds, a nightly import runs past midnight, and users are quietly complaining that \"the system feels slow\" without anyone being able to say exactly why. The frustrating part is that FileMaker rarely tells you which script is the culprit — it just... slows down.\n\nThis article walks through exactly how to find the specific script (or step inside a script) that's dragging your solution down, using tools built into FileMaker plus a few habits that make future slowdowns much easier to catch.\n\n## Why is it so hard to tell which script is slow?\n\nUnlike a web server with request logs and response-time dashboards, a FileMaker solution doesn't automatically tell you \"Script X took 4.2 seconds on Tuesday at 2pm.\" Slowness is often reported by a user in vague terms: \"opening the invoice window is slow\" or \"the export takes forever now.\" That single complaint could be caused by:\n\n- A script with an unindexed find\n- A loop that recalculates values it doesn't need to\n- A network round-trip happening once per record instead of once per batch\n- A layout with too many objects, unstored calculations, or portals loading on entry\n- A trigger (OnRecordLoad, OnLayoutEnter) silently running heavy logic in the background\n\nSo the first job isn't fixing anything — it's isolating exactly where the time is going.\n\n## Step 1: Reproduce the slowness with a stopwatch, not a feeling\n\nBefore touching any tool, get a real number. Have the user (or you) perform the exact sequence of clicks that feels slow, and time it with a phone stopwatch. \"It's slow\" becomes \"opening the Order Detail layout with 40 line items takes 6 seconds.\" This baseline matters because after you optimize, you need proof it actually improved — not just a feeling that it did.\n\n## Step 2: Use the Script Debugger to watch execution line by line\n\nOpen the Script Debugger (Tools menu, in FileMaker Pro Advanced) and step through the suspected script line by line. Watch for:\n\n- Steps that pause noticeably longer than others when you press Step Over\n- Loops that iterate far more times than expected (add a temporary variable to count iterations)\n- Nested script calls (Perform Script) that trigger other scripts you forgot were even running\n\nThis is slow and manual, but it's the most direct way to catch a script that's doing something unexpected — for example, a script meant to update one record that's accidentally looping through an entire found set because a **Go to Record\u002FRequest\u002FPage** step is missing.\n\n## Step 3: Use the Data Viewer to time specific expressions\n\nThe Data Viewer's Watch tab lets you evaluate calculations live while a script runs. If you suspect a particular calculation field or `ExecuteSQL` call is the bottleneck, add it to the Watch list and see how long it takes to evaluate against real data — not test data. A calculation that's instant on 50 records can take real time on 50,000.\n\n## Step 4: Instrument the script yourself with timestamp variables\n\nThis is the technique that gives you the clearest, most reliable answer, and it works in both FileMaker Pro and Server-side scripts (where the Script Debugger can't reach). Add these lines around suspicious sections:\n\n```\nSet Variable [ $start ; Get ( CurrentTimeUTCMilliseconds ) ]\n# ... suspected slow section ...\nSet Variable [ $elapsed ; Get ( CurrentTimeUTCMilliseconds ) - $start ]\n```\n\nLog `$elapsed` to a variable, a text file (via Insert File \u002F Get(DocumentsPath) export), or a dedicated Log table. Wrap each major block of a script — the find, the loop, the export, the commit — in its own start\u002Fstop pair. Run it once, and you'll have a table showing: find = 40ms, loop = 4,800ms, export = 90ms. Now you know exactly where to focus.\n\nFor solutions with recurring performance questions, it's worth building a small permanent logging table that records script name, step, duration, user, and timestamp on every run above a threshold (say, 1 second). This turns \"the system feels slow sometimes\" into a dataset you can actually query and trend over time.\n\n[[IMAGE:left|a script with timestamped checkpoints revealing one slow section]]\n\n## Step 5: Check FileMaker Server-side, not just client-side\n\nIf the script runs as a Server Schedule or via Data API\u002FOData, none of the above client-side tools will catch it directly. Instead:\n\n- Check the **Server Stats log** in FileMaker Server Admin Console for elapsed time per script schedule\n- Enable the **Topcall \u002F slow query** logging available in FileMaker Server's Database Server settings, which logs any query exceeding a duration you set\n- Review the **Client Statistics** in Admin Console during the slow operation to see if it's CPU-bound, I\u002FO-bound, or waiting on network round-trips\n\nA script that runs fine on a fast office network can become painfully slow for a remote user on VPN — the same script, the same data, a completely different bottleneck (network latency per round-trip, not the script logic itself).\n\n## What are the most common causes once you find the slow spot?\n\n- **Unindexed finds** — a Find performed on an unstored calculation field forces FileMaker to evaluate every record instead of using an index. Fix: store the calculation, or find on an indexed field instead.\n- **Loops with a Set Field inside instead of a batch replace** — updating 10,000 records one at a time in a loop is far slower than a Replace Field Contents or a well-formed script using `Get(FoundCount)` checks.\n- **Unnecessary Commit Record steps inside a loop** — each commit is a round-trip to the server. Commit once, at the end, when possible.\n- **Portals and unstored calculations on layouts** loading data the user never scrolls to see. Sorting a portal by an unstored calculation is a classic silent slowdown.\n- **`ExecuteSQL` queries without proper indexing** or run against tables far larger than the developer originally tested with.\n- **Chained scripts calling scripts calling scripts**, each with its own overhead, when a single consolidated script would do the same job with less back-and-forth.\n\nIf you're seeing several of these patterns across the same solution, it's often a sign of deeper structural debt rather than one bad script — that's the broader topic covered in our guide on [how to improve the performance and structure of a FileMaker solution](https:\u002F\u002Floggix.com\u002Fen\u002Fblog\u002Fhow-to-improve-the-performance-and-structure-of-a-filemaker-solution).\n\n## Can AI help find slow scripts faster?\n\nYes, increasingly so. Claris' own AI assistant, **Klai**, can read through scripts and flag inefficient patterns — such as loops that could be replaced with a Replace Field Contents, or finds performed on unindexed fields — much faster than manually stepping through hundreds of lines. It won't replace timestamp logging on your actual production data, but it's a useful first pass to catch obvious anti-patterns before you even open the Debugger, especially in solutions that have grown for years under multiple developers.\n\nLayout-related slowness is a separate but related issue: tools like **FMBetterForms** let you build lighter, web-friendly layouts that reduce the object count and rendering overhead FileMaker Pro sometimes struggles with on complex forms, which can make a layout feel faster even before you touch a single script.\n\n## A quick checklist for hunting a slow script\n\n1. Time the slow action with a stopwatch and note the exact steps taken\n2. Identify which script(s) run during that action (use Script Debugger or a Log table)\n3. Add timestamp checkpoints around each major block of the script\n4. Run it against realistic (not test) data volumes\n5. Check whether it's client-side or server-side, and test from both a local and remote connection\n6. Look for the common culprits: unstored calculations, loops with per-record commits, unindexed finds, chained scripts\n7. Fix one thing at a time and re-measure — don't change five things and hope\n\n## FAQ\n\n**Does FileMaker have a built-in performance profiler?**\nNot a dedicated one, but the Script Debugger, Data Viewer, and Server's Client\u002FStats logs together cover most of what a profiler would give you — you just have to assemble the picture yourself.\n\n**Why does a script run fast for me but slow for a colleague?**\nUsually network latency (remote vs local connection), a much larger found set on their end, or a privilege set that forces extra validation calculations to evaluate.\n\n**Should I optimize scripts proactively or only when users complain?**\nA lightweight logging table that flags any script run over 1–2 seconds is worth building proactively in any solution with more than a handful of users — it catches slowdowns before they become complaints.\n\n**Is a slow script always a scripting problem?**\nNo. It's often a schema problem (missing index, unstored calculation) or a layout problem (too many objects, portals loading unnecessarily) that only shows up when a script touches that layout or field.\n\nFinding a slow script is ultimately a diagnostic exercise, not a guessing game — and the habits above (timestamp logging, realistic data volumes, checking server-side separately) apply whether the solution is three years old or fifteen. If your team keeps running into the same performance questions without a clear way to track them down, or if a diagnostic pass reveals that the real issue is deeper structural debt rather than one bad script, Loggix can help — whether that means a hands-on performance audit, rebuilding specific modules with a cleaner FileMaker architecture, or introducing AI-assisted tooling into your day-to-day development workflow.","\u003Cp>Your FileMaker solution used to feel snappy. Now a button click takes three seconds, a nightly import runs past midnight, and users are quietly complaining that "the system feels slow" without anyone being able to say exactly why. The frustrating part is that FileMaker rarely tells you which script is the culprit — it just... slows down.\u003C\u002Fp>\n\u003Cp>This article walks through exactly how to find the specific script (or step inside a script) that's dragging your solution down, using tools built into FileMaker plus a few habits that make future slowdowns much easier to catch.\u003C\u002Fp>\n\u003Ch2>Why is it so hard to tell which script is slow?\u003C\u002Fh2>\n\u003Cp>Unlike a web server with request logs and response-time dashboards, a FileMaker solution doesn't automatically tell you "Script X took 4.2 seconds on Tuesday at 2pm." Slowness is often reported by a user in vague terms: "opening the invoice window is slow" or "the export takes forever now." That single complaint could be caused by:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>A script with an unindexed find\u003C\u002Fli>\n\u003Cli>A loop that recalculates values it doesn't need to\u003C\u002Fli>\n\u003Cli>A network round-trip happening once per record instead of once per batch\u003C\u002Fli>\n\u003Cli>A layout with too many objects, unstored calculations, or portals loading on entry\u003C\u002Fli>\n\u003Cli>A trigger (OnRecordLoad, OnLayoutEnter) silently running heavy logic in the background\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>So the first job isn't fixing anything — it's isolating exactly where the time is going.\u003C\u002Fp>\n\u003Ch2>Step 1: Reproduce the slowness with a stopwatch, not a feeling\u003C\u002Fh2>\n\u003Cp>Before touching any tool, get a real number. Have the user (or you) perform the exact sequence of clicks that feels slow, and time it with a phone stopwatch. "It's slow" becomes "opening the Order Detail layout with 40 line items takes 6 seconds." This baseline matters because after you optimize, you need proof it actually improved — not just a feeling that it did.\u003C\u002Fp>\n\u003Ch2>Step 2: Use the Script Debugger to watch execution line by line\u003C\u002Fh2>\n\u003Cp>Open the Script Debugger (Tools menu, in FileMaker Pro Advanced) and step through the suspected script line by line. Watch for:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>Steps that pause noticeably longer than others when you press Step Over\u003C\u002Fli>\n\u003Cli>Loops that iterate far more times than expected (add a temporary variable to count iterations)\u003C\u002Fli>\n\u003Cli>Nested script calls (Perform Script) that trigger other scripts you forgot were even running\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>This is slow and manual, but it's the most direct way to catch a script that's doing something unexpected — for example, a script meant to update one record that's accidentally looping through an entire found set because a \u003Cstrong>Go to Record\u002FRequest\u002FPage\u003C\u002Fstrong> step is missing.\u003C\u002Fp>\n\u003Ch2>Step 3: Use the Data Viewer to time specific expressions\u003C\u002Fh2>\n\u003Cp>The Data Viewer's Watch tab lets you evaluate calculations live while a script runs. If you suspect a particular calculation field or \u003Ccode>ExecuteSQL\u003C\u002Fcode> call is the bottleneck, add it to the Watch list and see how long it takes to evaluate against real data — not test data. A calculation that's instant on 50 records can take real time on 50,000.\u003C\u002Fp>\n\u003Ch2>Step 4: Instrument the script yourself with timestamp variables\u003C\u002Fh2>\n\u003Cp>This is the technique that gives you the clearest, most reliable answer, and it works in both FileMaker Pro and Server-side scripts (where the Script Debugger can't reach). Add these lines around suspicious sections:\u003C\u002Fp>\n\u003Cpre>\u003Ccode>Set Variable [ $start ; Get ( CurrentTimeUTCMilliseconds ) ]\n# ... suspected slow section ...\nSet Variable [ $elapsed ; Get ( CurrentTimeUTCMilliseconds ) - $start ]\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Log \u003Ccode>$elapsed\u003C\u002Fcode> to a variable, a text file (via Insert File \u002F Get(DocumentsPath) export), or a dedicated Log table. Wrap each major block of a script — the find, the loop, the export, the commit — in its own start\u002Fstop pair. Run it once, and you'll have a table showing: find = 40ms, loop = 4,800ms, export = 90ms. Now you know exactly where to focus.\u003C\u002Fp>\n\u003Cp>For solutions with recurring performance questions, it's worth building a small permanent logging table that records script name, step, duration, user, and timestamp on every run above a threshold (say, 1 second). This turns "the system feels slow sometimes" into a dataset you can actually query and trend over time.\u003C\u002Fp>\n\u003Cp>[[IMAGE:left|a script with timestamped checkpoints revealing one slow section]]\u003C\u002Fp>\n\u003Ch2>Step 5: Check FileMaker Server-side, not just client-side\u003C\u002Fh2>\n\u003Cp>If the script runs as a Server Schedule or via Data API\u002FOData, none of the above client-side tools will catch it directly. Instead:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>Check the \u003Cstrong>Server Stats log\u003C\u002Fstrong> in FileMaker Server Admin Console for elapsed time per script schedule\u003C\u002Fli>\n\u003Cli>Enable the \u003Cstrong>Topcall \u002F slow query\u003C\u002Fstrong> logging available in FileMaker Server's Database Server settings, which logs any query exceeding a duration you set\u003C\u002Fli>\n\u003Cli>Review the \u003Cstrong>Client Statistics\u003C\u002Fstrong> in Admin Console during the slow operation to see if it's CPU-bound, I\u002FO-bound, or waiting on network round-trips\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>A script that runs fine on a fast office network can become painfully slow for a remote user on VPN — the same script, the same data, a completely different bottleneck (network latency per round-trip, not the script logic itself).\u003C\u002Fp>\n\u003Ch2>What are the most common causes once you find the slow spot?\u003C\u002Fh2>\n\u003Cul>\n\u003Cli>\u003Cstrong>Unindexed finds\u003C\u002Fstrong> — a Find performed on an unstored calculation field forces FileMaker to evaluate every record instead of using an index. Fix: store the calculation, or find on an indexed field instead.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Loops with a Set Field inside instead of a batch replace\u003C\u002Fstrong> — updating 10,000 records one at a time in a loop is far slower than a Replace Field Contents or a well-formed script using \u003Ccode>Get(FoundCount)\u003C\u002Fcode> checks.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Unnecessary Commit Record steps inside a loop\u003C\u002Fstrong> — each commit is a round-trip to the server. Commit once, at the end, when possible.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Portals and unstored calculations on layouts\u003C\u002Fstrong> loading data the user never scrolls to see. Sorting a portal by an unstored calculation is a classic silent slowdown.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>\u003Ccode>ExecuteSQL\u003C\u002Fcode> queries without proper indexing\u003C\u002Fstrong> or run against tables far larger than the developer originally tested with.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Chained scripts calling scripts calling scripts\u003C\u002Fstrong>, each with its own overhead, when a single consolidated script would do the same job with less back-and-forth.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>If you're seeing several of these patterns across the same solution, it's often a sign of deeper structural debt rather than one bad script — that's the broader topic covered in our guide on \u003Ca href=\"https:\u002F\u002Floggix.com\u002Fen\u002Fblog\u002Fhow-to-improve-the-performance-and-structure-of-a-filemaker-solution\">how to improve the performance and structure of a FileMaker solution\u003C\u002Fa>.\u003C\u002Fp>\n\u003Ch2>Can AI help find slow scripts faster?\u003C\u002Fh2>\n\u003Cp>Yes, increasingly so. Claris' own AI assistant, \u003Cstrong>Klai\u003C\u002Fstrong>, can read through scripts and flag inefficient patterns — such as loops that could be replaced with a Replace Field Contents, or finds performed on unindexed fields — much faster than manually stepping through hundreds of lines. It won't replace timestamp logging on your actual production data, but it's a useful first pass to catch obvious anti-patterns before you even open the Debugger, especially in solutions that have grown for years under multiple developers.\u003C\u002Fp>\n\u003Cp>Layout-related slowness is a separate but related issue: tools like \u003Cstrong>FMBetterForms\u003C\u002Fstrong> let you build lighter, web-friendly layouts that reduce the object count and rendering overhead FileMaker Pro sometimes struggles with on complex forms, which can make a layout feel faster even before you touch a single script.\u003C\u002Fp>\n\u003Ch2>A quick checklist for hunting a slow script\u003C\u002Fh2>\n\u003Col>\n\u003Cli>Time the slow action with a stopwatch and note the exact steps taken\u003C\u002Fli>\n\u003Cli>Identify which script(s) run during that action (use Script Debugger or a Log table)\u003C\u002Fli>\n\u003Cli>Add timestamp checkpoints around each major block of the script\u003C\u002Fli>\n\u003Cli>Run it against realistic (not test) data volumes\u003C\u002Fli>\n\u003Cli>Check whether it's client-side or server-side, and test from both a local and remote connection\u003C\u002Fli>\n\u003Cli>Look for the common culprits: unstored calculations, loops with per-record commits, unindexed finds, chained scripts\u003C\u002Fli>\n\u003Cli>Fix one thing at a time and re-measure — don't change five things and hope\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Ch2>FAQ\u003C\u002Fh2>\n\u003Cp>\u003Cstrong>Does FileMaker have a built-in performance profiler?\u003C\u002Fstrong>\nNot a dedicated one, but the Script Debugger, Data Viewer, and Server's Client\u002FStats logs together cover most of what a profiler would give you — you just have to assemble the picture yourself.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Why does a script run fast for me but slow for a colleague?\u003C\u002Fstrong>\nUsually network latency (remote vs local connection), a much larger found set on their end, or a privilege set that forces extra validation calculations to evaluate.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Should I optimize scripts proactively or only when users complain?\u003C\u002Fstrong>\nA lightweight logging table that flags any script run over 1–2 seconds is worth building proactively in any solution with more than a handful of users — it catches slowdowns before they become complaints.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Is a slow script always a scripting problem?\u003C\u002Fstrong>\nNo. It's often a schema problem (missing index, unstored calculation) or a layout problem (too many objects, portals loading unnecessarily) that only shows up when a script touches that layout or field.\u003C\u002Fp>\n\u003Cp>Finding a slow script is ultimately a diagnostic exercise, not a guessing game — and the habits above (timestamp logging, realistic data volumes, checking server-side separately) apply whether the solution is three years old or fifteen. If your team keeps running into the same performance questions without a clear way to track them down, or if a diagnostic pass reveals that the real issue is deeper structural debt rather than one bad script, Loggix can help — whether that means a hands-on performance audit, rebuilding specific modules with a cleaner FileMaker architecture, or introducing AI-assisted tooling into your day-to-day development workflow.\u003C\u002Fp>\n","Jeroen","2026-07-24",1784901677000,[19,20,21,22,23],"FileMaker performance","script optimization","FileMaker debugging","Claris FileMaker","custom app maintenance","\u002Fapi\u002Fknowledge\u002Fimage\u002F375\u002F?v=4b5c652c792c",false,"",null,{"title":29,"slug":30},"FileMaker and Claris","filemaker-and-claris",{"title":32,"slug":33},"How to improve the performance and structure of a FileMaker solution","how-to-improve-the-performance-and-structure-of-a-filemaker-solution"]