As all the Xwidgets run within the context of the same process, high cpu usage in one widget can cause a drastic slow-down in all the others. When the host o/s dynamically lowers the priority of the xwidget process (a normal thing to do in a time-sharing system), all the widgets will appear to pause/hang for a period until the CPU contention is resolved in Xwidget's favour.
In comparison, due to its architecture and the way each yahoo widget runs in its own process, the yahoo widget engine is much more stable and if a widget ever does crash, it doesn't take all the other widgets with it. If a yahoo widget consumes too much cpu, other widgets will only be affected in the way that all processes will be affected, they won't instantly freeze or appear to hang. The negative side is that each independent yahoo widget consumes more resources than an Xwidget.
However, if you have a powerful and modern PC with a decent processor and plenty of memory (most do these days) the amount of resources that these widgets consume is really quite trivial on a modern quad core 3+ghz system. The system I am using now is an old core2duo, 2.5ghz machine and the load of running the xwidget and yahoo widget engines simultaneously with 20 or so widgets is low if not negligible.
Due to the way that all Xwidgets run within the same context, I find the stability of the Xwidget engine is questionable, especially when developing a new widget and running multiple other xwidgets simultaneously. When running highly animated gauges, the dock can become paralysed and sometimes your widgets refuse to initialise. Killing Xwidgets altogether seems to be the only solution. It is actually useful having a Yahoo widget that is designed (a big kill switch) to actually kill and restart Xwidgets and vice versa!
An architectural change is required within Xwidgets that allows the widgets to be run independently within their own process. This would bring stability to Xwidget.
|