Question: Having never used FMPerception before, would this tool be useful in diagnosing specific graph issues that could be affecting performance/speed?
Environment: FMS19, FMP19, Win 10.
Background: My Point-of-Sale (POS) system was created before the advent of Anchor Buoy. Therefore, the main sales screen is not an anchor. As a consequence, there are many relationships that may not be strictly related to processing a sale (creating an invoice line item, finding a product, adding the product, and calculating taxes/total). The end result is adding a product to an invoice takes five seconds, which I find excessive.
Before I start building a TOG based on the sales workflow, I’d like to use FMPerception to assess my current relationship graph and pinpoint issues/constraints/limitations.
It would provide data but your diagnostic skills will be needed to turn that information into knowledge. It's limited by the generated by the DDR which is essentially a bill of materials.
As an example, a layout may have many objects. Are they nested in a hidden panel or are they all on display? Portals may reference a TO that is one hop away from the current context or it may be ten hops. Are calculations invoked on objects? Do they test a boolean or invoke a complex algorithm that needs to pull data in from relationships or SQL queries.
You could work through all of those options looking for optimisations. Then you could discover that local CSS has been used everywhere instead of layout theme styles.
@Malcolm — acording to an RCC training video, unnecessary relationships strain FileMaker, presumably affecting performance. Eliminating those unneeded relationships is one of my goals and what I was hoping FMPerception could help with. (I’m already using BaseElements, so I’m hoping FMPerception could give me additional insights.) I’ll download the trial version and see what data and/or information it provides.
In my opinion BaseElements gives you more and better information than FMPerception. BaseElements, being an FileMaker database, has to load the DDR and build all of the related data sets before you can begin. That can take a long time, which is frustrating. FMPerception uses XML/XSLT processing to drill down into the DDR. In comparison, FMPerception is almost immediate and that is it's strength.
Hey, FMPerception is great, but it is indeed un-opinionated. It won't really tell you why a part of your solution is slow.
acording to an RCC training video, unnecessary relationships strain FileMaker, presumably affecting performance.
Don't take this at face value. While eliminating unnecessary schema is good, I'll venture that extra TOs/relationships are unlikely to be the performance culprit. They do affect startup speed, but not really general usage (with some exceptions). See this discussion:
My advice for performance tuning your solution is very unglamorous. Identify something about your solution that is slow, and dig into that issue specifically.
Maybe a list view scrolls slowly. Is it the unstored calculation that is showing on the line, maybe a slow conditional formatting. Maybe you're showing related data. Try removing objects until it's fast and zero in on the slow bits and try to fix those.
Or if you have a slow script... benchmark each section. Maybe it's the loop in the middle that's slow, or an ExecuteSQL call.
Does your solution open slowly, try disabling your startup script. If it's still slow THEN it might be the relationship graph that is slowing it down. But I wouldn't make any changes until you've tested a few hypotheses.
I’ve added timers to each of the three scripts that run when adding an item to a sale, but I have not benchmarked each section of each script. I’ll work on that — thanks for the info.
I’ve downloaded the trial — the script call chain graph is great. I’ll explore the other features for a few weeks then decide if I want to invest the $499.