List Performance

[wicky...@gmail.com]

Hi,

This is probably the fourth time i am posting about the performance of the list in the discussion forum. The issue was related to me trying to render containers in the list with my own layout and images inside. For flexibility in design, which might have not been the choice of many but of us, and our app which has successfully launched on android using codenameone platform.

The problem was that the list stutters, lags and create a tremendous performance issue sometimes crashes the app.
After a long session of hacking and cracking all the possible ways of using the Renderer and setting the properties to find a way to resolve it, i gave up and decided to write my own list.

I have literally copied the ContainerList to be my own, and the only thing i remember moving was the generic binding of the properties. That binds the hashtable values to the list items, objects like labels, images icon properties etc.

This, luckily, fixed the whole performance issue and it works as fast as any native list. I suspect the generic binding was eating up the performance and made it slow. It is the right methodology and perfect design, to do a generic bind, however nothing beats a fast performing list!..

Maybe, you will find the issue at its root and fix it, so we can enjoy the design :)

I am attaching the code and sample of how to construct and remove the performance issue.

Regards,
Wick

[Shai Almog]

Hi,
what generic binding?

[Wick S]

The binding u guys did to the hashtable keys values.
The way list renderer does...with

v.put(key,value)
And it automatically binds the values

On Aug 11, 2014 9:51 PM, "Shai Almog" <shai....@gmail.com> wrote:

Hi,
what generic binding?

[Steve Hannah]

So it looks like you've taken ContainerList and removed the renderer.  Then you're actually returning UI components from your model.  This violates the MVC design of lists.  Really what you were looking for was a plain container with a vertical box layout.  Using "Model" in the name of the NewsListModel class might create confusion with developers who later have to work with your code because they might expect the traditional separation of design from model that the naming convention implies.  But, hey, if you're the only one working with the code, then that might not be a concern for you.

For maximum list performance, you're probably best going with just a plain List with a custom renderer.  But this requires a different way of thinking about lists, models, and renderers, and has some limitations (e.g. all list items need to be the same height, and event handling of subcomponents is trickier).  Depends how important performance is to you.

Steve

On Mon, Aug 11, 2014 at 7:51 AM, Shai Almog <shai....@gmail.com> wrote:

Hi,
what generic binding?

--
You received this message because you are subscribed to the Google Groups "CodenameOne Discussions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to codenameone-discu...@googlegroups.com.
Visit this group at http://groups.google.com/group/codenameone-discussions.

To view this discussion on the web visit https://groups.google.com/d/msgid/codenameone-discussions/855a69a5-65e8-434d-9d31-dae4f4d74d36%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
Steve Hannah

Web Lite Solutions Corp.

[Wick S]

Well i havent done any same codes...just posting as a sample for discussion.

I understand the hard binding is a bit confusing and will not serve the mvc purpose of the design. I mentioned that it broke the design.

However i do think there is a way out....with the same heignt for each item able to be implemented as well. And somehow the binder for hastable values to component. If it can be fixed for performance it should solve the problem and i would be glad to use the traditional way.

For now performance is key when building a native app as it separates the phonegap and what we want to achieve.

I think if i decouple the model and allow coders to bind their own properties in the model it would be an mvc but strong typed...

Would loversion ure suggestions....
Regards
Wick

[Shai Almog]

Try it with a List not ContainerList which is effectively slow.
Renderer's are hard to get right so I'm assuming you hit one of the obstacles http://www.codenameone.com/3/post/2013/12/deeper-in-the-renderer.html
The code is pretty easy to compile and thus pretty easy to benchmark and profile.

[wicky...@gmail.com]

Hi Shai,

Thankz for the suggestion, i have tried if before, however the performance did not improvide until i got rid of these functions

 public Object getPropertyValue(String name) {
        if(name.equals("ListItems")) {
            Object[] obj = new Object[model.getSize()];
            for(int iter = 0 ; iter < obj.length ; iter++) {
                obj[iter] = model.getItemAt(iter);
            }
            return obj;
        }
        if(name.equals("Renderer")) {
            return getRenderer();
        }
        return null;
    }

    /**
     * @inheritDoc
     */
    public String setPropertyValue(String name, Object value) {
        if(name.equals("ListItems")) {
            setModel(new DefaultListModel((Object[])value));
            return null;
        }
        if(name.equals("Renderer")) {
            setRenderer((CellRenderer)value);
            return null;
        }
        return super.setPropertyValue(name, value);
    }

Then the performance increased 10 folds. To get rid of this, i had to break the MVC model and did a strong-typed bind of the container with the ListModel ...

My question per-se or discussion, was that how can the above function be improved so we (developers) can still use the MVC model.

As what i did is preferably a work around for now.

Regards,
Wick

[Shai Almog]

Hi,
these aren't the methods I was talking about. They should only be invoked a few times in a normal application.
I suggest overriding them and placing a breakpoint there to see who invokes them during application runtime and why.