store performance [Archive]

jakovdt

6 Aug 2010, 1:44 AM

Hi,
I'm a newbie of GXT. I'm looking for more information about how to use store and loader. I bought the book "developing gxt application" but there aren't enough technical details about the performance. I'm working on a complex project in which are large amount of data, so I must be very careful of the tools I use.

For example, I have a ManyToMany relation between Users and Profiles. So, one user has one or more profile. I thought to make a user CRUD with GRID Store Data Binding for users and a dualListField for profiles. I was wondering what the best strategy to to retrieve data and add a new profile to a user.

I can extend my user bean with all available profiles (and add a flag to know which are the ) or maintain the data in two different stores (one for user and one for profile).
To do this, I must know which is the lighter mode in terms of performance...
Thanks

J

Colin Alworth

6 Aug 2010, 10:49 AM

In general, storing data is cheap, and loading data isn't too bad, depending on the user's internet connection and browser/machine. Showing data is the very costly thing - finding ways to limit how much must be rendered at a given time is key to keeping your app fast.

Keeping your terminology straight can help with this a lot - there is no Grid store, but there is a ListStore with the Grid (and other components) are able to use. Filtering, searching, and sorting huge amounts of data can be expensive, depending on how many you are dealing with, but these are Store operations, and as such can be passed off to the server via a loader. Binding a form to a given record in a store is fairly trivial as long as you don't have too many fields, but showing many records in a grid is where things tend to get expensive.

If you are talking about 10s-100s of elements loaded at a time, the ListStore will have no trouble at all keeping up, but if you have 1000s or more, depending on the browser/machine, you could start to have trouble.

As I am understanding it, you are looking for something like this http://www.sencha.com/examples/explorer.html#gridbinding - a grid which lists many records, and a form to modify a single record. The many-to-many relationship you talk about seems to suggest that there is another grid which will appear and can be modified for each user - if each user has only a handful of elements in that second grid, I don't think I would add any extra round trip calls to the server for more data at all.

Perhaps a little more detail can make this easier - can you confirm some of the assumptions I have made or clarify your usecase? A lot of these decisions really depend on how much data you are talking about. If you keep your data and view separate, and use binding and other events to connect different parts of the app, you should be able to later stop loading so much data, and instead have the server provide more part-way through. The key feature in getting an app to work like this is remembering to keep components and data working in such a way that later adding async rpc calls will be easy.