FileMaker Inc. announced the release of FileMaker 12 this morning.
From a both a developer and UI perspective this is a huge release – new design tools, css-based applied themes, better charting, a new file format, server improvements – there’s a ton of stuff to talk about. It’s a little mind-blowing.
Fortuitously FM Academy announced today the 12 Days of FileMaker 12 Series - a free, open and comprehensive series of Webinars to run over the next month, covering in depth the new features in FileMaker 12, starting April 10. Register today.
IT Solutions, the sponsor of Philly FileMaker, is a member of FM Academy, and Jerry, Chad and I will be running three of the 12 webinars.
Happy FileMaking!
Colin
All those improvments are nullified to all who are using list and table view, they’re 3 to 5 times slower. Which makes every solution using list view / table view unusable (yes even with fully flat indexed data). The new drawing engine is terribly slow.
Please voice your concern here :
http://forums.filemaker.com/posts/715ef37320
To me that render 12 useless, and cast doubts on the future of Filemaker at my place,this speed issue seems deeply entrenched in new rendering engine.
So please don’t be quiet, voice your concern.
Ran those tests, and yep, the script runs slower.
I wonder if running a REFRESH for every 80 records accurately simulates scroll behavior, since I can manually scroll through the records significantly faster than the script itself can.
In fact I don’t see a difference scrolling manually through the benchmark file locally in 11 or 12 at all.
I’m sure that if the layouts were loaded up with conditional formatting, calc fields etc the performance different would be much more noticeable…
As far as I can tell in the example, it’s the REFRESH that’s the performance hit. disable that, and FM12 runs through the script faster – because the script engine is faster and/or the calc engine is faster.
Thinking about this more, I also wonder how this test performs when built FROM SCRATCH in both versions.
Maybe there’s something about the file conversion process that’s adding extra back end junk…
The refresh is needed because otherwise it doesn’t simulate what the user experience because the script will zap thru the end without bothering to update the display. I wrote that script because at first I noticed the performance drop using my files, so I wished to time it.
Maybe yes we should try to create the database from scratch but I’m doubtfull because slowness also occurs in table view mode wich we have not much control on.
In my experience calc engine is also slower : just looping in memory with variables is 20% slower
Well, there are lots of ways to test that assertion; probably the best way is with a custom function.
However within a scripted loop block, I don’t see any difference between 11 and 12 – they both loop through 1 million iterations in 60 seconds. I just modified your file as follows:
Re: refresh – I understand why you included it, my point was that it may not be an accurate representation of what really happens when you scroll through records. It does prove that either refreshes are slower, or scrolling is slower, but not which, or whether it’s a mix.
Not saying scrolling isn’t slower, mind you – just that I don’t think the test actually tests what you say it does.
A better test would probably be along the lines of the videos you shot, but on a raw file in both 11 and 12, with a human forcing the file to scroll continuously.
Hi Collin,
You’re right about the looping, I tested with the pre-release of FMP 12, and it was slower, but the GOOD NEWS is that the released version is much better, on par to FMP 11
https://rapidshare.com/files/280699396/variablestests.zip
However, there’s still other evidence of FMP12 slowness :
Hi Collin,
Did a manual timewatched scrolling test with a ntive FMP12 file, and an native FMP11 one (an xml file converted to fmp12 fp7)
FMP 11 : 1″14
FMP 12 : 2″50
Okay, now that I’ve seen you post this in EVERY single FileMaker oriented blog there is…I’m going to recommend people simply monitor the aforementioned FileMaker Forum thread and associated threads on the TechNet list.
I understand the concern – it’s real – but also find the ubiquity of the postings to be borderline spamming. This isn’t a political campaign, and the rhetoric…I don’t know, it just bugs me.
FMI is not the enemy. And you can bet they want this fixed MORE than you do.
I think it’s just information balance, everyone who’s interested, or concerned about Filemaker, should be warned about the seriousness of the issue. Every “review”, or PR post out there are only offering the glowing side, and for the 12th release the bad side overcomes it, and at least should be mentioned.
So gloving reviews / pr post can be considered spamming also, but false one.
Being a non coming back release, this is especially important to get real information, some jumped too fast and are regretting it badly.
Finally, in my very first post I just pointed people to the correct informative thread.
Not meant to bother you, just sharing important data with potential buyers
>>I’ve seen you post this in EVERY single FileMaker oriented blog there is
Maybe, but if nobody makes a fuss, then nothing gets changed.
I’ve been a filemaker user for decades and in fact very little has changed at all. Filemaker is able to create some of the ugliest and most user hostile databases around to the point that it is hardly surprising that Apple put it at arms’ length.
To combine that with a significant slow-down is very depressing. Having seen how fast and flexible plain MYSQL is, I’d love to find a way out of FMP.
D
Hi Dermot!
To your first point: The point of my comment that you quote is that the original commenter posted the EXACT same message on every filemaker blog, forum and announcement regardless of the context of the blog, forum thread etc.
Dialogue is useful, bug reporting is useful. Spamming just adds noise. I hope it’s clear that we don’t mind talking about issues here – or I wouldn’t have bothered to investigate the commenter’s claim and verify.
To the second point: It’s a design tool, and the attractiveness and usability of the end product – a software solution – is entirely in the hands of the designer. Ugly and unusable databases don’t just happen.
I would argue that the product line has been moving toward encouraging BETTER database design, by the way. It may not be immediately evident, for example, but the designer-facing tools in FM12 now allow for grid-based design using 960 principles (http://960.gs/). We now have tools in place to easily adopt principles widely used in web design for arrangement of information – which provides better affordance for what is increasingly a user base trained on interacting with informations systems designed on the web.
The slow down issue has been well documented by now, and potential causes identified (I’m betting the conditional formatting is the biggest culprit), so I’m hopeful a resolution path will come at some point. But since we’re upgrading many clients without problems, we’re not going to scour the web looking for places to complain about it – to my mind there are already places on fmdev and forums.filemaker.com to make these points; those conversations are happening there, and that’s the best place to have them.