[Metakit] blocked views
There is a faster implementation of blocked views in CVS now. It evolved from a change submitted by M. Berk (thank you!) and appears to have a considerable effect on performance. The trick is to cache the last used subview. If you use blocked views and check out the latest code from CVS, you will see. If you don't, let me just say that blocked views are now a good option for very large views. Performance benefits are particularly good for views with many properties, and when traversing them sequentially. To switch to using blocked views, change code which looks like: vw = store.getas(vw[...]) to vm = store.getas(vw[_B[...]]).blocked() You'll also need to reload data, this change won't convert it for you. With a somewhat lower raw access performance, you'll get much more scalable views (millions of rows and more), faster commits, and smaller datafiles. There's no need to switch over every view - it's still a trade-off. If your views are rarely modified, or contain no strings, or are always accessed in random order (hash maps), then flat is often still better. But it's there if you want it. -jcw _ Metakit mailing list - [EMAIL PROTECTED] http://www.equi4.com/mailman/listinfo/metakit
Re: [Metakit] blocked views
Jean-Claude Wippler wrote: With a somewhat lower raw access performance, you'll get much more scalable views (millions of rows and more), faster commits, and smaller datafiles. There's no need to switch over every view - it's still a trade-off. If your views are rarely modified, or contain no strings, or are always accessed in random order (hash maps), then flat is often still better. But it's there if you want it. I'll just throw in my two cents. I switched my application over to blocked views a couple of months ago and have never looked back. I began to have a problem with random-access and hash maps around 100,000 objects in a particular table. Eventually the database would refuse to commit data anymore. The solution was to convert to blocked views and use .blocked().ordered() for random access of key values. In practice, there has been little noticable difference between the application using hashes and the application using .blocked().ordered() One caveat is that when searching the blocked and ordered tables you should use search and not find for a couple of reasons described on the mailing list. Currently my database is over 1 gig and the main table has 1+ million entries. One to one joins are still incredibly fast on such tables and I couldn't be happier. Suffice it to say, that I'm all for any improvements in blocked table performance. Brian -jcw _ Metakit mailing list - [EMAIL PROTECTED] http://www.equi4.com/mailman/listinfo/metakit _ Metakit mailing list - [EMAIL PROTECTED] http://www.equi4.com/mailman/listinfo/metakit
