genevieve charbon

> capsprojectos Please send this here : http://forums.filemaker.com/posts/715ef37320 This os the thread FM Inc monitors for those speed issues

So why FMI didn't create such numeric ones ? to make FMP slower once more ? How do you make such a conversion ? Thanks for this very interesting Post !

There's no problem converting 11 to 12, aside the problem that 12 is slow as hell no matte what, and buggy, so you should stay at 11 untill FMP12 v2 perhaps or wait 13. as for files, I'll continue to have seperate files, but work in one only : one big file on which you put all the other files as reference (so you'll buil the relationship in that file), so you'll have the est of the 2 worlds, one code for all, but less risk of data corruption

No it will be slower, and terribly slower if you use List View and Table views. Plus, Filemaker IS NOT 64 bit, only Filemaker Server is 64bit. My script, like yours, are 10% to 20% slower (aside from list view which is unusable). Server is faster, but client is so slower that it doesn't matter aside from specific things like: - Containers, - Valuelist - Perharps find But you can donwload the trial and see for yourself

The refresh script step here is the most simple one, not flushing any caches. It is mandatory otherwise FileMaker will not redraw, and hence it won't simulate user browsing. But actually FMP12 Refresh is slower than FMP's 11 (one more thing amongst many things that are slower in 12), but it's slowness only account a little vs the Redrawing flow down as you can see it with true manual scrolling !

Steven, 1. Manual scrolling means looking at each record, so that involves clicking in the bottom of the scroll bar again and again till you reach the end, as a user would to to scan each records. So that involves many click. It's not drag an dropping the screen bar from top to bottom, so if you're not clicking at least 30 times (many more I think that's why I scripted it !) you're not testing the list redrawing as you only force the final screen to redraw. 2. Optimizing the script by freezing the display makes no sense at all, the script is the way it is to simulate what a user would see if he'd scroll the list himself. Of course this script is no about going from top to bottom. And for those who might think why on earth do we need to scroll 60k records, the answer is simple it's a benchmark designed to show clearly a speed loss. Why did I wrote it, because I use lust view as my users daily with 600 to 1000 records, and weekly with 3000. And of course the problems shows

Steven, Please take a look at that file, both the scripted test, an do some manual scrolling with the different layouts, and tell us your experience, so we can have common ground. https://rapidshare.com/files/829418137/bench.zip

Pre-release is slower than Final on certain things (looping in memory was 20% slower), but as far as scrolling speed the release version as also the issue By the way, Bruce Robertson nailed the issue : the layout description is huge, layouts can gets 3.75x bigger. So this is a design issue, it won't be fixed soon on tech net https://fmdev.filemaker.com/message/76896#76896 And that confirm me deepest fear, we're screwed for a long time. Unless they didn't do the obvious optimizations of storing this in binary format, and compress it, they won't have much room to improve the situation which is flawed by design.

Hi Steven, FM Inc acknowledged it, i sor it's real, t occurs on mac and on windows. Me I'm on mac 2.6 corei7 April 2010 15" MacBook Pro 10.7.3 There's a file to download in the link

@Littlebrookie : it doesn't just appear slower, it is, a lot. Even with a completely flat file with all field indexed In fact, almost everything is slower in FMP 12, Filemaker 12 is just slower across the board (like 10/20%) but for list / table vie is much worse 300 to 500% slower. Please, go to the link I posted and voice your concern, we can't let that happen. List vew was already slow (unstored field etc), and needed a speed boost already, not a terrible regression. Please don't be quiet, voice it there : http://forums.filemaker.com/posts/715ef37320

Hi, Take a look at this, list view and table view became so slow that upgrading to FMP 12 is simply out of the question for me http://forums.filemaker.com/posts/715ef37320

Hum, which log file ? where ?

3.34 doesn't work better either !

except I use CryptographyMD5Hash( text )

I've exactly the same problem; latest 3.33

Seems to me it will be a performance killer ?

Thanks comment, The auto-update did the trick

when user hads a sku in the group a script willbe trigered that will update the group key. so the key remains indexed

The key will be generated when the user puts the sku in the group, so it will be plain text and will get indexed.

Yes the ordering seems a good idea but it only works just during the creation of the group. If the user changes the order afterwards, then it doesnt work. The goal is to have an indexed key. So valuliest aren't possible. Of course, we can recrate the key when user changes the order that's true, but cumbersome

Hi, I have a group of unlimited products, the each group group_id SKU sku_order 1 AJ 1 1 OK 2 1 LM 3 I want to create a key for performance reasons for each unique group which is the concatenated SKUs so the key of group one would be AJ OK LM But to me the sku order is just a cosmetic issue, for my use LM AJ OK would be the same so I'd like to generate a key that's the same regardless the order. so I need a trasnformation that would give the same result f(AJ OK LM)=Key f(LM AJ OK)=Key Key=Key

Hi Ray, Sure there's no flush cache data, it's just you refresh script pasted as is. With your method using $$variable it needs a refresh to work, and that's slow in my design. Casading related calculation and related fields. I think you're right to think yours is faster IF there was just plain indexed data (an maybe the uLearnit method with global field is still faster - one step less but also less reliable as I heard off - not exeperienced). The webviewer speed is constant regardless the number of records shown (or it seems so). Yours and ulearnit's is slower than the number of records grow (and I mean with related and calcs). But with few or plain fileds yours could be fatster than webviewer. Also I use it in a networked FMS 10 cleint server situation on Mac Os X Leopard. So not standalone solution. Of course your method is much simpler to implement thanthe webviewer one. Maybe my design is not effecient, but webviewer with it is faster. I'd really like to be it to be more effecient. Basiacly there's fields that are displayed that involves calculations F1 : Related1::A*Related2: F2 : F1 * Related3::C F3 : F1*1,196 plus just some plain related fileds. Let me ask you how to write the above effeciently ? Would F1 : Related1::A*Related2: F2 : Related1::A*Related2: * Related3::C F3 : Related1::A*Related2: *1,196 be faster ? What do you mean by "graph redundancy" ? In my experience, as soon s as you use related data Filemaker is slow, and that bothers me a lot ! Thanks

Thanks Ray, Amazing work as always. BUT, the Highligth row is slow ! It's not the fastest way. The webwiever trick is MUCH faster. The reason is that your's requires a refresh window. Try it with hindreds records in list view with some of them comming from related fileds and unstored cals, and you'll the slowness. ulearnit uses a global field and in my experiences doesn't require refresh windows step. http://www.ulearnit.com.au/blog/?p=55#comments However webwiever still is way faster. P.S Record highlight is mostly usefull when you've a huge number of records, so the slowness is a big issue. So FM Inc, you still need to have a built-in way to do this !

Hi Wim, did you succeeed ? how ?

Yes, just don't update, its slow as hell, stick to 9