What language is FMPerception written in? I noticed it was very slow yesterday with a several-hundred MB DDR.
I think one of the reasons it seems slow is that there weren't any progress dialogs -- just a beachball for minutes at a time.
Thanks,
Can you see what makes that XML DDR so big? Are there big base64-encoded nodes in there?
Nope. Just a really long file for a big app.
Again, a simple progress dialog instead of a beachball would be a welcome improvement for a professional product at this price point.
Thanks,
There's a way to handle this: Ask @DaveRamsey. He's the only one that can support it well enough in terms of questions of its language and its speed. Feel free to send a support ticket to support@geistinteractive.com.
You mention the price point: With that comes great service from a great team. Feel free to use that avenue rather than a forum post.
2 Likes
Slow also depends on what you are doing. Initial load does show a progress bar. There are a few tasks that are slower also. Our DDR is 1.3 GB. Load only takes about 6 secs. A few tasks take about 15-20 secs, the first time only.
Remember, you are not dealing with a straight XML search. There is a LOT of intelligence behind what it is doing. Without that intelligence, the XML is no better than the HTML version.
The "price point" was part of a reply to another poster, not the original posting.
I'll send an email too, but I'm currently only an evaluation user.
Thanks,
why did you remove your comment about the price point above?
I didn't. It's still in the reply. It was never in the original posting. 
Ah. sorry about that.
Well I hope FMPerception works for you. It seems to work for lots of folks. Dave can give you lots of good information about the inner workings of it.
1 Like
FMPerception is a great product! I really like it a lot.
This huge DDR is possibly bigger than most, I have no idea.
I sent an email as you suggested. I agree that the support and dedication from this company is amazing.
Thanks for following up.
3 Likes
Hey, sorry for the slow response here. I'm not generally hugely active on this site, and it took a little while for me to figure out exactly what I wanted to say.
Some specific answers:
- FMPerception is written in Swift on macOS and C# on Windows. Everything is compiled, native code.
- "several-hundred MB DDR" is a little indeterminate... is several 2-300 MB, or 6-800MB? The performance difference between those two can be... noticeable.
Now, some details. There are 2 separate issues here. The first is "progress".
The nature of the way that FMPerception generates its data is often not particularly conducive to getting progress feedback. For example, to get a list of all of the layout objects on all the layouts is one single line of code. Now, this doesn't generate all the metadata about those items (columnar and detail sidebar data), but it indexes that list in a single command. There's no way to get progress feedback on that. I could change that code to use one query per layout, and then be able to use the individual completion of those smaller queries to generate a progress bar... but that's substantively more complex code, and a little harder to maintain (a lot harder if I then multithread those queries). My general approach has been to optimize only those queries that users are having difficulty with. If it only takes you a 1/2 second to get a result, my time would likely be better spent elsewhere than getting that down to a quarter second. And not uncommonly, many smaller queries is slower than one big query. The parser is already optimized for doing the big query, so trying to do my own optimization does the opposite. But if you're experiencing something slow, I would like to hear about it. The specific query you're running and the size of your DDR are both critical data points. Whenever I can get a zipped copy of a DDR, that is also very helpful.
Then, there are some queries that don't lend themselves well to progress. Unreferenced Objects is one. First, find all the objects of a particular type (not easily progressible). Second, find all the references to that particular type (also not easily progressible). Then, cross reference the two lists, and identify all items in the first that don't have anything in the second (maybe progressible).
So, if I had progress bars, many of them would have to be indeterminate anyway.
The second big topic is the beachball, and that's on me. FMPerception is my first substantive, completely native app (huge really, about 35-40,000 lines of code per platform). As a long-time FileMaker developer, one of the things I did not completely anticipate is the complexity of some of the more involved queries, and what would happen when running them synchronously vs asynchronously (code running synchronously is what causes the beachball). Asynchronously running queries also has some very complex impacts on the app UI/UX. If it's async, and the app doesn't stop you, you can click on a second query before the first has completed. Then, the app returns the result of the first... but that's no longer the query you're clicked on. So, cache that result, but then ignore it UI-wise, unless the user clicks back to the first query. Of course, now we really need progress bars, but not just for the app, but for each query individually... And once we have that, you'll definitely want to be able to cancel a query that's going to take longer than you would like... And in 2015, that was just beyond my capability, especially when the UI needed to act basically the same on both macOS and Windows.
I'm better at that sort of thing today, and supporting detailed progress and fully async operation was one of the original design requirements for FMComparison. Shoehorning it back into FMPerception at this point would be architecturally complicated. Very.
Eventually, FMPerception is going to get a ground-up rewrite, primarily to take advantage of the new XML. In some ways, FMComparison has functioned as a testbed for a completely new architecture, allowing me to figure all of this in a slightly smaller app... that needed to be written anyway. And while it's still in beta, it has already been a huge success for exploring these architectural challenges.
Hopefully this has clarified some of the issues and complexities, and my apologies for the beachballs. At this point in FMPerception, they take the role of indeterminate progress bars.
In the future, I hope to improve that situation.
12 Likes
Thanks very much, Dave. Superb reply.
To answer your questions, the DDR in question was between 200 and 300 MB. The beachballs were happening when scrolling down the various high-level menu items. Getting a Report Card took quite a while (some kind of progress indicator on what's happening especially with the "Slow" items you reference on the main form would be helpful). The program appeared to be hung (it wasn't).
Thanks again for your kind reply You guys rock.
The report card is the slowest thing, primarily because it runs all of the above queries and then aggregates/manipulates the results.
That said, it would probably be one of the easier (for a given values of “easy) queries to do progress on... until the sync/async thing bites me in the butt.
It’ll be better in the future.
I would also say that clicking down through the queries is possibly the worst case performance-wise you could test with. Lots of great big queries with large return sets run one after another.
1 Like
+100