I'm investigating an issue with some performance in one of my UWP ListViews. This listview contains about 1000 items and the content of the listview item is injected via ReactiveUI's ViewModelHost.
It seems like when I remove the ViewModelHost and replace it with the actual control (i.e. not letting ReactiveUI determine which control to place) my performance increases dramatically.
My suspicion is that the content in the ViewModelHost is not being virtualized and is being re-created for every cell. Is this correct? Is ViewModelHost the recommended approach for listviews with large sets of data?
Related
Is it possible to perform stealth paging on a sap.ui.table.Table? By stealth paging I mean, when scrolling (up or down) only a batch of records is retrieved. The current page is removed and replaced with the next batch of records. I don't want a technique that continuously appends to the data because I have a last button and it would take forever to load everything.
Would I use something like getThreshold() found here?
Tables in sapui5 already have this built in.
a Table control can take care of only rendering the currently visible rows and use this ScrollBar control to make the user think he actually scrolls through a long list.
This can be found here.
SapUi5 is even cooler than I originally thought!
What would be more efficient in a kinda big application for a mobile application? Make a separate TabItem for each menu item or have one TabItem with an empty Rectangle that will become parent of the form of each Menu Item's Unit?
(I assume you mean reparenting the controls on a child form to appear within a container on your main form. If so you'll need to use (e.g.) a TLayout which will handle child controls better rather than a TRectange).
It depends what you mean by 'efficient'.
One big form will take longer at start up and consume more memory.
Creating content on demand will take longer at run time as each form is created and destroyed.
In most of the Activities and Places examples I've seen, people use a SimplePanel as the display for an ActivityManager.
I was wondering if there's a benefit to using a DeckPanel/DeckLayoutPanel instead of SimplePanel. It's fairly trivial to create a wrapper around a Deck panel that implements AcceptsOnWidget.
I haven't seen this topic discussed anywhere. Prior to MVP+Activities being commonly used in GWT, people generally used Tab panels (which internally uses deck type panels) and Deck panels to control switching between panels within a given view.
The difference between the two is SimplePanel.setWidget(..) will remove the previous child from the DOM and append the new widget whereas a deck type panel will use CSS to control visibility of the current panel (i.e. "display: none" to hide inactive panels).
If using a deck panel, it generally means you will have much more Elements in the DOM. I would imagine this uses more memory and makes the application "sluggish", even if those nodes are not visible ("display: none"). Is this true?
If this is true, why did Google use a deck panel style impl for TabPanel/TabLayoutPanel instead of internally using a SimplePanel?
Is one approach more favorable over the other?
Performance wise there is no difference. It all depends how you use it. In the DeckLayoutPanel all children are kept in memory. But if you would implement the same thing with a SimplePanel you need to keep a pointer to those same children yourself, so the memory footprint would be about the same. Unless with a SimplePanel you create and render a child each time it's shown and throw it away when hidden, which would possible be memory efficient (if the garbage collector does it's work), but it would be a hit on usability since rendering is expensive.
Second if you use a DeckLayoutPanel all it's children are created at once, while only one is shown. For performance this might not be optimal. So for this reason you could add a LazyPanel between the child and the DeckLayoutPanel, so it's only created when shown. But that might take some extra coding to make it work (because it's lazy you need to lazy initialze it which can cause some difficulties) However, still for the comparison between DeckLayoutPanel and SimplePanel it's only a matter of when you would create the children for the SimplePanel (all up front == same issue as with DeckLayoutPanel) and not something specific to the difference between DeckLayoutPanel and SimplePanel.
In general if you have a defined ordered set of children use a DeckLayoutPanel (like with a TabPanel) and if you have a undefined set SimplePanel is the better choice (like in MVP to show the current view).
DeckLayoutPanel internally holds collection of all your views (actually views that you've registered or displayed) in order to be able to determine sliding animation direction (depending if you go back or forward). Apart from this, I didn't notice that application become sluggish when switched from SimplePanel do DeckLayoutPanel. It's especially safe, when all your views are singletons. But please aware that in such case, when switching between the same view instance (for example main categories list -> subcategories list), DeckLayoutPanel may have some problems rendering sliding animation.
In my opinion there is no favorable solution - if you don't need "sliding" panels, I would not use DeckLayoutPanel (since all additional components increases complexity).
I'm really struggling with a choice between the GWT Tree widget, which has been a part of GWT for ages; or the new CellTree, which is introduced by GWT 2.1.
The tree I want to present to the user is not particularly large, but I am very concerned about responsiveness.
The data at the nodes of the tree will be editable. By clicking on a node, the user will put the node into edit mode. Editing the more simple nodes will require only a single TextBox or TextArea; but others will involve several widgets, over which I want styling control via CSS.
I'm attracted to the CellTree approach because it seems to offer great flexibility and speed; however, the sample code for CellTree editing deals with only very simple data types: string, date, integer, etc. I don't know if CellTree is appropriate when you've got more complex node-editing needs.
What do you think? Is CellTree the best approach? Does CellTree replace Tree in general? What heuristics can I apply in choosing between them?
I'm using a CellTable with several custom input Cells, including one comprised of many widgets. It works great!
It took me a couple of hours to understand how to implement a custom Cell that could do complex operations - since a single instance of the Cell will flit around the CellTree, pretending to be many instances, you need to understand how it's getting its data and when it is refreshed and rendered. I learned a lot from the source of the DatePickerCell.
I can't speak for CellTree, but the CellTable is very flexible, was easy to program, and saves me hundreds of Widget instances.
Using CellTree is problematic. Because it hasn't good access to view implementation stored in CellTree. It cause problem (ex. for me :D) in making custom handlers for opening nodes with children by clicking on whole parent cell. Of course you can make custom cells by AbstractCell, where you must write own renderer.
I think this widget must be enchanced and more objects must be more visible for users.
Customizing CSS is simple. All what you have to do is extende CellTree.resource and insert own css based on celltree.css class names.
I've yet another question. I'm working with GWT 2.0.4 and IE8 as well as FireFox (the latter only for comparison purpose). My application needs to load data and show it inside a table. There are about 60 columns and 150 rows to show.
Since the loading is dynamic - as soon as a dataset has been fetched, it's added to the table - I'm fine with slowdowns during loading process. However: when the table is completely loaded, I'd expect it to be pretty snappy and let me scroll it without much lag.
While the loaded table reacts in FireFox pretty good - it stays very responsive - Internet Explorer 8 is causing me a lot of headaches. In particular: as soon as the table finished loading and I try to scroll around or highlight a row, IE8 becomes VERY laggy and highlighting a row makes IE8 consume 50+% of CPU power.
I am not using any 3rd-party libraries and even displaying empty cells in a FlexTable still gives me the same issue.
I found some probably related issue here: SmartGWT ListGrid is slow, but only in Internet Explorer . Unfortunately neither the issue there, nor the supplied links for SmartGWT solved my problem as I am not using SmartGWT. I do believe though that the problem is related.
I'd be happy to try any suggestions.
If it's possible (and your description of the problem suggests so), use Grid instead:
A rectangular grid that can contain
text, html, or a child Widget within
its cells. It must be resized
explicitly to the desired number of
rows and columns.
Have a look at bulk table renderers # GWT Incubator for a comparison of these approaches (it's a little dated, but the point that FlexTable is slower than Grid still holds ;)). The "bulk rendered" tables from the incubator are also an option, however keep in mind that those widgets might not be maintained any more (and for example, contain bugs) - or are rapidly maintained :D But looking at the source might at least point you in the right direction, if you wanted to roll out your own solution to this problem.
highlighting a row makes IE8 consume 50+% of CPU power.
Maybe it's because you added mouse listeners to every row in your table. If so you could use :hover-pseudo-class in your css-files.
This article maybe helpful if you need to handle Events from a bunch of widgets in your table: http://code.google.com/intl/en/webtoolkit/doc/latest/FAQ_UI.html#As_the_application_grows,_event_handlers_seem_to_fire_more_slowl