# General-Purpose Read Method, Take Three

**URL:** <https://the.fmsoup.org/t/general-purpose-read-method-take-three/5722>\
**Category:** Questions\
**Tags:** optimization, performance, filemaker-architecture\
**Created:** [August 31, 2026, 12:02am UTC](https://the.fmsoup.org/t/general-purpose-read-method-take-three/5722 "2026-08-31T00:02:11Z")\
**Posts on this page:** 2\
**Page:** 2

<div class="post-metadata">

**Author:** ![karimhanafi](https://avatars.discourse-cdn.com/v4/letter/k/9e8a1a/32.png) [@karimhanafi](https://the.fmsoup.org/u/karimhanafi)\
**Post date:** [September 27, 2026, 11:43pm UTC](https://the.fmsoup.org/t/general-purpose-read-method-take-three/5722/21 "2026-09-27T23:43:52Z")

</div>

@Kirk , sure. Stripped down to the basic idea, the construct looks something like this:

```auto
While ([
~result = "" ;
~i = 0
] ;

~i < ~recordCount ;

[
~i = ~i + 1 ;
~result = ~result &
            JSONSetElement (
                "{}" ;
                ["fieldA" ; GetNthRecord ( Table::fieldA ; ~i ) ; JSONString] ;
                ["fieldB" ; GetNthRecord ( Table::fieldB ; ~i ) ; JSONString] ;
                ["fieldC" ; GetNthRecord ( Table::fieldC ; ~i ) ; JSONString]
            )
] ;

~result

)

```

The actual expression is quite a bit more complicated because part of its job is also to produce the exact result shape I want from the method. I attached the full expression I am currently using if you want to look at the real thing. But the harvesting idea itself is basically what you see above.

Your point about `Evaluate()` and injection is a good one. In this case, though, none of the harvested data is inserted into the expression being evaluated. The generated expression contains the field references. The actual record values only enter the result when `GetNthRecord()` executes.

Performance surprised me. Replacing the script-level record traversal with the generated `While()/GetNthRecord()` collector gave me roughly a 2× improvement at that stage of the implementation. That change is really what made the performance of the read method start becoming acceptable.

I haven't tried to establish that this is the fastest possible way to harvest the data. What I measured was this approach against the script-level traversal it replaced.

[queryResult.txt](https://the.fmsoup.org/uploads/short-url/jkIr4j3PAouyryaURaUPEQOuMNd.txt) (4.9 KB)

---

<div class="post-metadata">

**Author:** ![Kirk](https://yyz2.discourse-cdn.com/flex030/user_avatar/the.fmsoup.org/kirk/32/2197_2.png) [@Kirk](https://the.fmsoup.org/u/Kirk)\
**Post date:** [September 28, 2026, 1:15pm UTC](https://the.fmsoup.org/t/general-purpose-read-method-take-three/5722/22 "2026-09-28T13:15:17Z")

</div>

I wonder if you replaced the JSON with ICR?

JSON - not just in FileMaker, but universally - is not a highly performant data format; it contains a lot of overhead to maintain the structure - a structure that might be easier to built in JSON, but at a cost. However, not looked at the full calc yet, so maybe there is some logic in using JSON.

IDK if you have explored this, but the JSONParse command may be a way to further increase performance while maintaining the JSON construct.

> **[Optimizing JSON performance - Working with the JSON functions](https://help.claris.com/en/pro-help/content/json-functions.html#optimizing)**
>
> Whenever a JSON function parses text input, the JSON parser creates a binary (not text) representation of it to make later processing of the JSON faster. There's an automatic mechanism to parse and cache JSON and an explicit one: the JSONParse...

Part of the personal bias may be that as a 20+ year FM dev, many of these "new" additions are useful, convenient, and rapid time-to-value, but not all of the long existing, finely tuned legacy syntax are good candidate for replacement.

[Previous page](https://the.fmsoup.org/t/general-purpose-read-method-take-three/5722.md?page=1)