Databinding, replication and performance

[mrhattyhat]

This is going to be kind of a hard one to explain in detail, so I'll stay at a high level and hope to get some general direction from all you LZX pros.

The basics: I'm working on a calendar app that behaves similar to Outlook's "month" view. It's working, for the most part, and allows adding of events by dragging across multiple dates, etc. The data, which includes all the dates, scheduled events, etc, are provided by a PHP script. Like I said, it's all working (for the most part) the way I need it to.

The problem: now that I have the basic functionality working, I'm noticing that the more events I schedule, the slower the app is to load. For example, when I first load the app clean (no events), it loads up pretty fast; but as I add events, it takes more and more time to respond. Obviously this is not ideal.

So, keeping this a high level "this is what it could be" kind of question, what are the most likely culprits for this slowing? Replication? Databinding (should I be using datapointers more rather than datapaths)? I tried switching the replication to lazy and, apart from introducing some weird rendering behaviors, there was zero performance improvement.

What are your thoughts?

Oh, it should be noted that I dumped the XML output from the PHP script and copied it to a local file, then tried loading the same data as a static XML file rather than a remote run-time call. There were no performance problems in that scenario at all. It loaded immediately, even with a bunch of events. So the problem only seems to be present when loading the data at run-time. It should also be noted that I can access the PHP script directly in the browser to see the XML output and it responds almost immediately, so the slowing doesn't appear to be network latency either.

I'm not asking for someone to solve my problem, necessarily; but rather for a few general pointers at where to look to gain some performance improvements in a data-driven app of this nature.

[mrhattyhat]

I found the solution.

Here's the nutshell:
I was trying something I'd never done before. I had created an "event" class with some attributes and a view in it. The view had a couple of methods. As each "day" of the calendar was rendered, an operation (dataset node check) would determine whether or not there was an event scheduled for that day. If so, I would instantiate my "event" class. I wanted to try this approach to creating views on the fly as opposed to just instantiating a new LzView because I figured I could pre-define all the attributes and methods that I wanted the "event" view to have at creation. I was rather pleased to find out that this lesson worked.

The Caveat: it's dog slow in this case. After trying everything else I could think of, I finally resorted to re-writing the code so that rather than instantiating my "event" class, I would just build a new LzView from scratch on the fly and then assign all the attributes and methods once it was built. It's not as pretty, by any means, but it's lightning fast and, from the user's perspective, it works exactly the same way...only faster.

So, after all that, I have no idea why the one approach is faster than the other. Maybe some of you LZX pros or the development team would care to comment on it? I'd certainly be interested to know.

[Lobo]

I am also building a big app, with many windows, each of them using classes at many levels (re-using code as much as possible).

I do notice several performance problems, although I need to look at several other places as well to try to improve performance (I'm not ready to do this yet).

But I am wondering if using classes (which themselves contain other classes at several levels, with placements and such) does create performance problems, compared to when using direct views (without all the nested classes, and unfortunately without all the lots of code re-use) ... ?.

Thanks.

[spoco2]

Hi, I know you posted this ages ago, but I'm just looking for all and every way I can to eek more performance out of our app.

I just wanted to see whether your issue was that the class that you defined with a view in it, was it defined as
[code]
<class name="fred">
<view name="innerfred"/>
</class>
[code]

If so then the fred class would have been an extension of 'view', I only discovered this recently, if you don't include an 'extends="anotherclassname"' then it'll default to extending view, so you'd have, in effect, a view within a view, thereby doubling the number of views required. That would slow things down. (extends="node" is about the lowest level you can get I think for laszlo based classes). You can make lighter classes again by defining them purely in javascript, but I haven't really looked into that all that much.

Also, why wouldn't you make the class be an extension of view, and not have another view inside? The class can be the visual view AND contain all the required logic as well, thereby being only the one view.