I don't doubt your results regarding the versions, but I do wonder if your testing environment is optimized and providing consistent results:
- Are your test files FM11 and FM11-converted-to-12 otherwise identical, as well as your import sources?
- Are you running your tests consistently against a form view layout as opposed to any list view layouts in all cases? And are you freezing the form-view layout screen before running each test? If not, the layout screen generation in 12, reading CSS fo redraws may be slowing your process in 12.
- Are all version tests run on the same CPU?
- Are these files local or served? If served, are the Server CPUs and networks identical?
- If you are using a scripted Loop operation for the Set Field tests, what is inside the Loop?
I expect Set Fields to be faster than Imports because no records need to be created during set field operations. Even updating only existing records via import will be slower than Set fields, especially if using a match field.
Keep in mind that, if you have WAN users, the speed improvements in 12 for WAN users will be a boost you shouldn't forfeit just to avoid import and set field issues. WAN speed improvements make the other speed concerns seem minor by comparison with 11 across a WAN.
I took a FM11 file and converted it to 12v2 for my test.
Used a custom function to time scripts.
List view – freeze window before Loop.
Both 11 & 12v2 were run on the same local computer.
Inside Loop – Set number fields to calculation fields. I also tried setting number fields to equations in the scripts and got identical results.
Another developer confirmed my results. He too started with FileMaker II.
The FM11 program used for the test was a backup copy that I took off a server. The program has been in cloud service for almost two years. The only thing it lacks is performance. FileMaker has to do something about performance or FileMaker Pro will die a slow death. None of my developer friends have converted their files to 12v2. FileMaker 11 is too slow and FileMaker 12v2 is unacceptable.
Thank you for your help,
Stephen, you bring up some good points. And there are more I'm sure. If you have played with FileMaker for long you have run into situations where small adjustments can make large differences.
I'm finishing a conversion/re-write of a complicated medical app and so far am very pleased with performance. And what are we to do....
a few statements run slower so I essentially give up my business? I know I won't find an acceptable alternative.
A global view is needed here, FileMaker is in evolution to the future of computing, perhaps ahead of others in their market niche. Each iteration can't be considered a finished/final end. We just can't jump from the present to the end point. FileMaker is smart in moving in a calculated fashion. I believe in their vision and I know from experience that this community is one of the best around. I'm willing to work within the confines of that evolution; that will keep my products, in their market, at the forefront.
Nice to see you here, sorry to hear that the v2 update didn't improve things for you although I'm not surprised. I still think 4D or Wakanda or Servoy are your best bet for your application. Good luck!
Servoy, 4D, Wakanda, Panorama, RealBasic,....and others..... they all require learning or leveraging other (sometimes multiple) technologies and languages. Why not learn how to use SQL, PHP, XML, native FileMaker as it was intended and retain the ease and beauty of FileMaker development? If the others work, then yes, FileMaker really isn't the right tool and comparisons are irrelevant.
Otherwise....see 'ya back here in a month or two.
In John's case he has a hosted app so FileMaker isn't really the right platorm for that type of solution unfortunately which I why I suggested the other products. Yes FileMaker is easy to develop with and I have been doing it for 20 years and made a good living at it but now I have some commercial solutions that I have created and wish to try and sell more widely and while I would like continue to use FileMaker for them it's clear that it's no longer the right platform for those kinds of solutions. FileMaker gives you great tools to create solutions but virtually zero tools to manage and maintain them and increasily this is becoming a problem for what I need to do and 12 only makes this problem worse unfortunately. It's true that many people (me included) complain about FileMaker's short comings but now I have come to terms with appreciating it for what it is and recognize when it's time to move onto something more suited for the task at hand.
In the case of 4D they use they own language plus it can speak SQL as well but it's basically FileMaker on steriods (it has it' own interface builder and it's own database) and while not easy to learn it's feature set can run circles around FileMaker. It's a professioanl tool for building professional applications which is the situation I now find myself in. From my perpective I'd rather spend my time learning it so I can create some truly amazing solutions while continuing to support and create .fp7 solutions then spend my time learning the limited new set of features in 12 that none of my customers need or want.
It was John, not me, who indicated that FM12 performance was unacceptable. I've been using FM since it's first unnumbered release under the FileMaker name, and won't be considering abandoning it after decades together.
I agree entirely about small tweaks making huge performance differences, but I also understand that people without long-term experience don't always see how to implement a particular feature or action more than one way. One has to understand the various options available to make the right choice for best performance. If one only knows one way to do something in FMP, then it's natural to blame the FM product for any poor result.
I figure that until I have thought of at least 3 ways to do something in FMP, I'm not ready to make an informed choice about which way is best.
Understood. I was agreeing with you and talking to John; only time I'm multiphasic I'm also confusing:)
I'm certainly not downplaying the capabilities of other systems or the role they can play. As stated I've taken a careful look myself. I'm sure the reason I stay with FMP is that it fits my needs. And I agree too, after soooo many years invested in FMP, I'd rather take the challenge and make FMP do it.
Experience with a system does have its advantages as you say. Hopefully through forums such as this we all can help those with less experience understand the full capabilities of FMP and thus be able to enjoy the possibilities rather than giving up with a poor attitude towards the product.
John, if your solution is hosted app as Lemmtech mentions, there is a change that another technology might be better choice, but I would not give up so quickly.
You had a reason to choose FileMaker and whether the reason was rapid development, client user experience or anything else, you now have an app whose "only issue" as you wrote is its performance.
I understand your hope to improve the performance by simply upgrading to a new version of FileMaker, as this would be the easier way. I also understand you're not happy to find out that in your case this approach does not work. But in my experience even versions that brought significant speed improvements did not increase the performance by more than a few tens of percent.
I think the best way for anyone having performance issues with anyting (not only FileMaker) is an efficient optimization. And by efficient I mean focusing just on the bottleneck and nothing else. Check out my video at http://FMBench.com/bottleneck to learn what I mean.
If your app's bottleneck is in import scripts, I suggest you focus on finding a way to optimize that. Yes, I see you have already tried that - by trying to use looped Set Field instead of the Import Records script step, but if your results are still not sufficient then why do you give up? Why don't you keep trying? If you belive that you can optimize it further then you'll find a way.
What data are you importing? Have you tried sending the data to the server as a file and importing it using a server-side script? Have you tried a different data format? Have you tried ExecuteSQL instead of native import?
Don't give up and good luck!