Speed and compilation

[Simeon]

Hi,


I just installed the DR server for a first time and tried to look at some of the samples.

I don't know if I did something wrong (just default install, not making any changes) but:

1) it seems that the server compiles the samples every time (I expected to do it only once)
2) general speed of execution is rather slow.

It is just me or this is some kind of debug more release?

My machine is rather slow, but not that much, everything sled runs pretty well.

Regards,
Simeon

[antun]

Hey Simeon

Yes there is a bug with the developer release - it does recompile every time. This bug does not appear in deployment.

As for the general execution, do you mean compilation or run-time speed? What kinds of things are slow?

Take care,

Antun

[Simeon]

Hi Antun,


With this bug it takes quite a long time (up to about a minute to compile on my machine) for the server to respond.
It is difficult to separate the compile time from delivery time.
In general I was expecting a bit better performance from the client side as well, but I hope that there is an area for improvement.
For now it feels like it's not base on Flash, but on some kind of Java technology ;-)

Is there way to get a copy of the server that has this bug fixed? I am trying to evaluate your technology before investing more time and efforts and it not easy with such problems.

Best regards,
Simeon

[antun]

Hey Simeon

I'm looking into whether you can get the bug fixed version for evaulation.

As a rule the system is designed not to recompile every time, but only when necessary.

The version of LPS that is installed on our server now is the fixed one, so have a look at these:-

http://www.laszlosystems.com/lps-dr/sample-apps/index.html

Compilation time is affected by your server environment - so if you're developing on a slow desktop, that will slow it down. When you deploy, you'll typically install the LPS on a server that doesn't have desktop applications sharing resources with it.

What machine are you running the LPS on?


In general I was expecting a bit better performance from the client side as well, but I hope that there is an area for improvement.


Again, I'm not sure what you mean exactly. What do you mean by performance? Can you give me an example? We are working on optimizing client speed, and view initialization.

-Antun

[antun]

That's extremely slow.

Originally posted by Simeon
With this bug it takes quite a long time (up to about a minute

[Simeon]

>Again, I'm not sure what you mean exactly. What do you mean by performance? Can you give me an example? We are working on optimizing client speed, and view initialization.

Well, I am talking about the "feeling" of speed, how responsive the UI is to user actions.
Right now your samples (except Weather) feel either just a little bellow the level of responsiveness ot quite slow (Contacts manager app?).
To illustrate my point:
ActiveX controls feel fast becuase they run as native code.
Flash - pretty much the same as far as it's own native effects are used. When used as a platform - to program casino games for example - it slows down a bit, but it is still very fast.
Java applets - AWT is so-so, SWING is slow due to the interpreted nature of Java. On fast machine are mich better, but still one can notice the lack of speed when more demanding tasks are concerned.
Dynamic HTML - fast for small popup menus at least.

Since your technology is based on Flash I expected to see almost no delays on the client when user interaction in concerned.
Again I am talking about user interaction only - I do not know if there is server interaction as well at the same time that could slow it down.

Was I more clear this time?

Regards,
Simeon

[antun]

Hey Simeon

Try a simple example:


<canvas width="800" height="800">
<view name="globe" resource="globe.png"
onmousedown="this.dragger.apply()"
onmouseup="this.dragger.remove()">
<dragstate name="dragger" />
</view>
</canvas>


Run it here:-

http://www.laszlosystems.com/lps-dr/my-apps/antun/speed/speedtest.lzx

Let me know how it runs on your machine. On my box, when I click and drag the globe around, it responds immediately. How fast is the computer you have speed problems on?

As for the more complex apps, they will respond a little slower because they are more complex. However it shouldn't be painfully slow.

For example, on the Contacts app, can you tell me:-

- How fast/slow it is when you drag the window?
- Is it slow when you make the window smaller?
- Is it slow when you make the window larger?
- If you pull up the details for a contact, is it slow when you click say, the Home tab?
- Is it resorting the contacts that's slow?

I have an old 600MHz box at home that I've run all of the sample LZX apps on with perfectly satisfactory results.

Take care,

Antun

Icon generously provided by http://www.iconfactory.com/

[Simeon]

Hi Antun,


This test runs very well (I mean fast enough ;-).
Any chance of getting fixed server code? When is the next version coming?

Best regards,
Simeon

[antun]

Hey Simeon

I've asked about the fixed server code, and we don't have it packaged up handily to deliver and support. It's not a formal release you see - it's just a bug we found immediately after DR was launched and fixed it on the website. What exactly is this for? If you have a specific project in mind, then we may be able to help you, but otherwise you will have to wait until our next release. The date of the next release is not yet set.

What specs (OS, speed, etc.) is the computer you're developing on? The one that the sample apps were painfully slow on.

Take care,

Antun

[Simeon]

Hi Antun,

The machine in question is a 400 MHz Celeron (P3?) with 256 MB RAM and good HD.

I just tested again your Animation demo (the first in the list) locally. The speed of execution when it get delivered to the client is fine, but the compilation time takes almost a minute (or least it seems so ;-).

As I mentioned before I am trying to evaluate your product. I like the idea very much, but it is the implementation that will make me use it in real projects at my clients sites.

Right now I can even show it to them because of that bug. I don't know when you are planning to have a fixed version, but you can tell your colleagues that this is killing the momentum.
You have to play nice at least with your initial developer base if you want to succeed, IMHO.

Best regards,
Simeon

[Simeon]

Oh, I forgot - I am using Win2K Prof as OS.
Another thing - I am experienced Java developer, if you can deliver to me not a full packaged solution, but just some classes/files to replace I can manage to fix it on my own I hope, with some instructions from you, of course.

S.

[antun]

Hey Simeon

I'm afraid we really can't give you a partial release right now.

However, if you're using a 400MHz Celeron system, I don't believe the slow speeds are the result of compilation. We found an old 400MHz laptop here at work and ran Contacts on it. The compilation was not a problem at all. However the view instatiation (which happens every time an app is loaded) took almost 50 seconds. Then I saw the slowness you described - the menus would take a moment or so to appear, the window would drag slowly. Scrolling was a pain. etc. I haven't witnessed this slowness before, that's why I was so surprised with what you described originally.

FYI view instantiation in Contacts is the second progress indicator (the one that is in a window and says "Starting Contacts").

I think that it's fair to say that that's around the minimum speed that complex Laszlo apps are going to run on. In other words, they will run, but very slowly. Like I said, I have an old 600MHz box at home that will instantiate views in Contacts in about 8 seconds or so, and the app responds smoothly.

Take care,

Antun

[Simeon]

Hi Antun,

In this case (not having fixed code right now) please notify us/me when the next release is available.

I would really like to show some cool looking Web apps around. I have few projects that I would love to try using Laszlo as a front end and test people's response.

Best regards,
Simeon

[antun]

Hey Simeon

We've just released an updated version of LPS-DR which includes the fix to the recompile-every-time bug.

It's available at:

http://www.laszlosystems.com/developers/download/

Take care,

Antun

[Simeon]

Hi Antun,


Congrats on the new release!

I downloaded, installed and tried the new version.
The bug that was causing compilation all the time seems to be fixed.
One question - the startup time is still rather long (but acceptable, again, on my rather old and slow PC), is this debug or release type of build? Is there any kind of initialization thet goes over the network that can explain part of the delay?

Best regards,
Simeon

[antun]

Hey Simeon

Glad to hear you downloaded the new DR release!

Yes, in effect this is a "Developer" release, so it's not intended for deployment. The true deployment version is faster in terms of server performance (mostly to do with data handling handling), so it would not affect the slow startup time you're seeing (which is a result of view instantiation on the client).

We are working on speeding up startup time and overall client-side performance.

-Antun

[rrcone]

Simeon:

I have read all of your posts concerning the slow load and execution speeds. I too am experiencing the same problems. I have compared the load and user interface response times of the Laslo Contact demo to Macromedia's Pet Store demo. There is a noticeable difference in load and user interface response times between both demos. I have ran both locally and online at Vendor's site. In both cases the Macromedia's app runs considerably faster considering it is accessing a backend database (Access). I am disappointed in both the lack of an RAD IDE and the response of the compiled Flash coded produced by the Laszlo complier.

[Simeon]

Hi rrcone,


I think that there are at least 3 factors that will explain to some extend why it is slower on my test machine:

1. The machine itself is rather old (amd slow)
2. It seems that the build we are using is not a complete "release" build, meaning that it contains debug code which makes it slower that the final version will be.
3. I am not sure, but I suppose that on the client Laszlo sits on top of Flash (or is it integrated with it somehow?). So I guess it is being "intepreted" by Flash and thus slower than native code from Macromedia.
I was planning to ask here (the forum) about this issue (how it is working on the client side).

Excepts if you are not rinning it on a very fast machine and it is still slow, I wouldn't be very concern about the speed though.
What is more important, in my opinion, is what kind of advantage it gives to it's developers. I have to confess that I just recently started going deeper into it. I am yet to look at how to make more complex applets with Laszlo (like the Contacts sample). Unfortunately the documentation seems not to cover the more complex apps yet, or may be I am missing something?

What are you interested in doing with Laszlo?

Best regards,
Simeon

[antun]

I'm not sure if that's a fair comparison at all. The Pet Market demo doesn't use any constraints at all. For example you can't resize anything. On the other hand the window alone in the contacts app contains many views that are listening out for updates about the others' size. Not only can you resize the window but you can also change the widths of the colums of data.

The Pet Market demo is also cleverly designed to be light on the client processor - for example, when you click on a particular breed of dog (or any other animal for that matter), instead of animating the entire detail window to full size, it animates a blank colored square, then applies the contents (photo of animal and details) to the rendered area.

There's also a substantial difference in the amount of data that these two apps appararently deal with.

The point that I'm trying to make is that the Contacts app is a pretty complex app for the client to render - if you could realistically build such a project using the Flash authoring environment, it wouldn't run any faster than the Laszlo version.

Take care,

Antun


Originally posted by rrcone
Simeon:

I have compared the load and user interface response times of the Laslo Contact demo to Macromedia's Pet Store demo. There is a noticeable difference in load and user interface response times between both demos. I have ran both locally and online at Vendor's site. In both cases the Macromedia's app runs considerably faster considering it is accessing a backend database (Access). I am disappointed in both the lack of an RAD IDE and the response of the compiled Flash coded produced by the Laszlo complier.

[antun]

Hey Simeon

Laszlo doesn't really sit on top of Flash. The SWF file format is basically a good bytecode format for 2D graphic applications.

There are a number of libraries that the LPS includes in the SWF it sends to the client that make the initial download larger.

Does that answer your question?

-Antun



Originally posted by Simeon


3. I am not sure, but I suppose that on the client Laszlo sits on top of Flash (or is it integrated with it somehow?). So I guess it is being "intepreted" by Flash and thus slower than native code from Macromedia.
I was planning to ask here (the forum) about this issue (how it is working on the client side).

Best regards,
Simeon

[Simeon]

Hi Antun,


Regarding the speed comparison: Yes, I agree with your that what you have with Laszlo is different, it seems to give more power (I am not that familiar with Macromedia, that's why I am hesitant to generalize) and therefore comparing the row speed is not fair.

For not being on top of Flash - good to know. You guys make the source code of the Contacts app available, right? But do you have as weel some documentation that covers building such applets - how to define menus, how to handle dialogs and so on?
I read the tutorials, but they seems to end pretty early, as far as classes and functionality is concerned.

I guess I can read directly the class descriptions, and combined with the source code should be able to get the idea, but in general it will be helpful for your developers to have this info.

I believe that if there is one area where your product will have an advantage it will be building relativaly large and complex on-line (Internet or intranet) applets WITH the same look, feel and functionality on multiple platforms - essentially better Java.

Best regards,
Simeon

[Simeon]

Hi Antun/Anne,


(I am sorry, but your "private" messages doesn't seem to work - can't search for names.)
I was talking yesterday to my partner and the discussion came to the point where he asked how much it will cost us to use your technology.
I did a rather short search today on your website, but came empty handed.
Can you tell me more about your pricing, license policy?

Best regards,
Simeon

[antun]

Hey Simeon

Right now it's still "talk-to-our-sales-department" about pricing for a particular project.

sales@laszlosystems.com

Take care,

Antun

[Anne]

Hey Simeon -

Sorry about the delayed response -- I've been in a sales meeting for a couple of days. The pricing is capacity-based licensing. You can call me directly for a quote!

Best,
Anne.

___________________
Anne H. Harrison
Director of Partner Relations
anne@laszlosystems.com
Direct: 415-241-2746

[ows]

Originally posted by Simeon

One question - the startup time is still rather long (but acceptable, again, on my rather old and slow PC), is this debug or release type of build? Is there any kind of initialization thet goes over the network that can explain part of the delay?

Most of the startup time is spent creating the views. (That is, it's purely in client computation, and doesn't involve the network.) One way to address this is to use the initstage attribute to delay the initialization of views that aren't needed immediately, until the user is already interacting with the application. This does make your application more complex to understand, so we recommend not doing this until you've otherwise got it working (unless you need some existence proof along the way to show that it eventually can be optimized this way).

A future release of the product will improve the startup time more dramatically and automatically. This is technology that we've prototyped, but won't productize until after 1.1.

[Simeon]

>A future release of the product will improve the startup time more dramatically and automatically. This is technology that we've prototyped, but won't productize until after 1.1.

This is great news. Any idea when ver. 1.1 might be coming?
Another issue related to this one - how this is going to affect the CPU load?
I run _just_ the client on a faster PC (1 GHz AMD Duron with 384 MB RAM) and noticed that the CPU utilization was rather high when using the contacts sample app.
I guess the initial jump to 100% is explained by the startup initializtion, but even after it, when using the application the CPU load was going something like 50-60%. Is this Flash related or something else?
Does the client side contain any debugging code?

On another note - I am still waiting for some pricing info. I really hope that Laszlo is free for certain applications, because there seems to be quite a compatition out there in this area.

Regards,
Simeon