Several things come to mind that suggest more of record caching issues than layout.
Has your existing record count increased in the past 2 weeks? Are there more related records for the network to cache when displaying a portal? Are you working on a LAN or WAN connection?
I note that removing the portal seems to "fix" your display redraw time, but putting the portal back on (which requires related record caching, even without visible fields) increases it again right away.
Are there any of the old speedy layouts which use the same relationships for portals? If so that suggests the layout is the issue, if not, then it's more probably caching issues.
Thanks for the quick response Stephen.
Our record count has increased by a few hundred records, but its a marginal gain of less than 1%, so its not a likely culprit.
We are working on a LAN. I've done a fair amount of work on diagnosing the network, and everything seems to be ok.
The old layouts do use the exact same relationship in the exact same context. That's whats so weird...I'm stumped.
Ouch. Your answers suggest the layout is the cuplrit, which is bad news. Can you post a screenshot of your layout so we can see what all it has, and maybe somebody here will have a clue from their experience as to which elements may be issues.
It is disturbing how many complaints about performance 12 has raised, and the newer layouts seem to be a prime concern.
By the way, have you done the latest updates for both Server12 and FMPro12, some of which were supposed to address performance issues?
Apparently our IT guy did not update the server. I'll try that tonight and get back to you.
Have you been playing with the different themes?
There is a bug with themes that can cause real slow down if you play with several themes even if you don't save them. The recommendation is to play with themes in a dummy database and then when you know what you want go back to your real database and select only that one.
As far as I know, every single layout we have applies the classic theme. I've never used themes on this database. We've pretty much created our own styling. Thanks Gary.
Can you point to more information about this bug?
I think qwinzeler is refering to the reports that came out at DevCon about CSS being added to the file each time a theme is applied to any layout. Apparently FMP doesn't remove unneeded CSS code once it has been written to the file when applying a theme, so FMP12 files have some level of CSS bloat from each and every theme that has ever been applied, even if it was later changed or even if the layout was deleted.
This is similar to how some programs like DreamWeaver add local CSS styling in an HTML file, but don't remove the "Style" code when the styled object is changed or removed later.
It would be great if FM can fix this with some type of optimization process, but the newness of CSS in FM12 may have made this a surprise.
Well, I'm not sure this is going to be useful for anyone, but I can tell you how things are working currently;
We did the server update, and it didn't change performance much.
I recreated the layout from scratch, and for some reason it seems to run much faster. There is still a disparity in the performance of the layout loading in OSX vs XP, and I have no idea why. The disparity is much larger in layout mode than browse mode, so I am working on my mac most of the time.
I have no idea why adding each field, portal, etc from scratch lead to such enormous performance increases, but the layout loads in 1-2 seconds now instead of 6-8 seconds like before. This might sound crazy, but I am EXTREMELY confident that there weren't any hidden objects on the layout or any 1px by 1 px objects that were on the old one causing the problem. So here's what I'll say in conclusion.
If you have a layout with very poor performance, rebuild it entirely from scratch. Take care to replace every text label and data field, even though it seems illogical that those could be causing the problem. You can have layouts that run at different speeds depending on your operating system...not sure why. Thanks for all the feedback guys.
Thanks for the follow up Lance. One test we sometimes do to pre-qualify suspect layouts is to simply select all the objects and then use the new "remove all styles" button in in the inspector. If your speed goes up then you are looking at a well stocked fridge and a re-do.
Now that you have determined and executed on your solution, I would be curious to go back and see how the remove all styles pre-qualifier trick works on your old layout.
Fascinating! It went from 6-8 seconds down to 1 second...that was it.
Thanks for the tip...it does bring 2 questions though;
1) Do you have any idea why OSX can render the styling in 1 second but it takes XP 6-8 seconds?
2) Why was it that when I created the styling from scratch (a lengthy and time wasting process) it lead to such dramatic performance increases?
In the OLD days ( before CSS ) for a "mature" layout ( the victim of numerous edits ) it would help to SELECT ALL, CUT, and PASTE it back
This somehow improved screen redraws
> Why was it that when I created the styling from scratch it lead to such dramatic performance increases?
I suspect the different performance between Mac and XP is basically a hardware issue. Macs tend to come with better graphics processors on basic models, and Win machines vary a lot more in hardware. Might even be local processor speeds, but it probably will come down to hardware when the same file performs differently on different platforms.