Sorry for sliding in late into this thread (vacation).
But have a look into this thread:
http://qooxdoo.678.n2.nabble.com/Degraded-performance-in-large-Forms-after-migration-from-qx-0-7-to-1-2-pre-answers-and-questions-tp5354116p5354116.html
It might be of interrest when discussing DIV usage and speed.
Am 31.08.2010 20:03, schrieb Jim Hunter:
Petr,
I have been using qooxdoo for a few years now and all along I have
been looking at other possible solutions. So far, nothing even comes
close to comparing to qooxdoo. Yes, qooxdoo creates a lot of DIV's, no
one is disputing that, but that alone does not mean it's slow or that
they need to be reduced. I found out early that if you pool your
objects, then when you need them again they render incredibly fast. I
was able to speed up my app almost 100% by pooling my objects. And it
also had the nice side effect of reducing memory leaks. So, what I am
saying, is that just because you see a lot of DIV's, don't immediately
think that this makes the toolkit slow and that there aren't ways to
make things faster.
We use qooxdoo to create a browser version of our Windows program.
When you compare the 2 apps now, they have the same look and feel, you
just can't easily do this with the other toolkits. And in some places
in our app, the browser version is faster then the Windows version, so
I have no complaints at all right now on speed. If your app is running
slow, post some examples to the list and let us help you determine
what is really causing your slowness, your issue might not be
completely the fault of the toolkit.
Jim
On Tue, Aug 31, 2010 at 5:12 AM, Petr Kobalíček
<[email protected] <mailto:[email protected]>> wrote:
let me summarize this discussion:
1. TaskSpeed is not relevant benchmark for this topic. I'm talking
about speed of qooxdoo and not some css selector stuff which is
irrelevant. The speed killer is count of needed DOM elements per
application/widget, not javascript size or css selector speed.
Just look how many DOM elements are created for simple button, this is
really not about selectors.
2. Qooxdoo will be never for classic web-apps for speed/size reasons.
I can accept that, but the qooxdoo community have to accept that
qooxdoo will never spread (for me this is not problem at all).
3. I will never post here another qooxdoo critique mail. I have
feeling that critique is not welcome here and I really tried to be as
objective as possible.
I can understand that qooxdoo can't be good for everything, but really
think that the performance should be improved, this is all I wanted to
say...
Best regards
Petr
------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:
Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
_______________________________________________
qooxdoo-devel mailing list
[email protected]
<mailto:[email protected]>
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:
Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
_______________________________________________
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
--
Mit freundlichen Grüßen
Dietrich Streifert
--
Visionet GmbH
Firmensitz: Am Weichselgarten 7, 91058 Erlangen
Registergericht: Handelsregister Fürth, HRB 6573
Geschäftsführer: Stefan Lindner
------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
_______________________________________________
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
