Re: Our (real) problems

[Michael Meeks <michael ximian com>]

Hi Guys,

On Thu, 2001-08-30 at 23:34, Alex Larsson wrote:
> Reading the flame-wars and discussions currently raging on the gnome
> lists makes me sad. Disagreement on technical decisions always exists
> in projects, but the level of the discussion is way too low and the
> topics are not what i perceive as the actually important ones.

	I couldn't agree more.

> Take for instance the discussion on whether gnome-libs should use the
> GConf API or the Bonobo-conf API to access the configuration
> database. The arguments are heated on both sides, but let me clue you
> in on a little secret. It doesn't really matter!

	Again, I broadly agree.

> Here is a list problems that I think are serious enough to make our
> users fall on their ass laughing if we do not fix them. I don't think
> any of them are unsolvable, but I see far to little work being done on
> them, and far to much time spent "interesting" peripheral projects.

	Yes - we need to focus on getting Gnome 2.0 frozen and functional.

	So lets discuss some of the technical issues, you point out several
pertinent topics.

> * Gtk+ 2.0 is way to late
> * GObject has severe performance problems
> * Object activation is unstable

> OAF / Bonobo Activation has problems with the lifetime of servers.

	Indeed - this should be relatively easy to fix - gconf has gone some
way to trying to solve it - but really we need the gconf work done
inside bonobo-activation.

> I often get a bunch of nautilus-news processes running that makes the
> sidebars crash when I start nautilus. This problem sort of ties in
> with the next issue.

	This is really a symptom of the lifecycle issues I think, and not
actualy bonobo-activation's fault - although, of course, if when oafd
dies these factories are re-registered a large chunk of the problem
appears to disappear for single user machines, since we don't fork
redundant wasteful processes.

> * Bonobo distributed refcounting does not work

	Indeed - it really doesn't - and here is the proposed solution for
Bonobo 2.0;

	For control aggregates and out of proc. components we set the imortal
flag on the aggregate. This effectively makes ref / unrefs a no-op;
consequently ref counting has no effect. Instead we track the linc
connection on the exposed interfaces and listen for the "broken" signal
- and slave the lifecycle to the domain socket breaking.

	So for the factory we terminate when all our controls die.

	Of course - as an alternative we can use the normal ref counting, and
then use the broken signal as a evil last resort to tear down the
object.

> The current "solution" for this is that each application ships with a
> gruesome hack of a script that you have to run now and then to clean
> up (examples: killev, nautilus-clean.sh and oaf-slay).

	Yes - this really sucks.

> Darin did some early work on using leases instead of ref-counting,
> which may be one solution to this problem. But no work has been done
> on this since then.

	Darin and I discussed the above, and he was investigating this instead
last time we talked.

> * Bonobo UI handler is slow and uses much memory

	Currently true.

	In fact, it seems the vast majority of slowness is not due to the
things people would imagine on looking at it. The whacking scad of
string compares it does eg. removing them gives no appreciable
performance increase. It seems that the slowness may well be down to X
resource handling, or pixmap handling etc. I have some benchmarks that
show stupid things happening with scaling stock pixmaps in Gnome 1.4
that takes forever.

	Anyway - lets look at the profiling data here.

> The bonobo ui handler works by sending xml data over Corba to
> specify the application window ui (menus, toolbars etc). This is a
> very flexible and easy way to handle user interface creation and ui
> merging. Unfortunately it does currently have a performance
> problem.

	:-) The problem is really coming up with a sensible, flexible out of
proc UI description methedology that doesn't involve excessive
roundtrips etc. etc.

> The result of this is that opening new windows and switching
> "components" (i.e. in evolution) is slow, which gives a very bad
> performance impression. When people do something they need to get
> instant response, or they will feel that the application is slow and
> get irritated.

	It's not clear to me what the slowdown is - but xmon ( apparently )
shows some evil pixmap resource thrash.

> Some work has been done on this recently by Michael Meeks and me, but
> I still think there is lots of work to be done here.

	I think the memory usage issue is substantialy fixed, certainly in
Gnome 2.0 with the quark and representation shrinkage work that I've
done in BonoboUINode - indeed, we could probably save a load of memory
in oafd - important for multi-user machines; oafd = ~1Mb real memory
usage per user ...

> * Too many libraries
> 
> Our current development platform really has to many
> libraries. Applications on the higher levels in the dependency chain 
> drag in a ridiculous amount of libraries. This causes performance
> problems with symbol lookup and increases startup time. Part of the
> startup time can be fixed by using ELF prelinking, but part of it is
> inevitable.

	Yep - again - difficult to know how to 'fix' this really.

	Anyway - it's great to have some constructive discussion - I'd be most
interested in grappling some more with these problems, and getting to
the real issues.

	Thanks for your constructive mail Alex,

	Regards,

		Michael.

_______________________________________________
gnome-hackers mailing list
gnome-hackers gnome org
http://mail.gnome.org/mailman/listinfo/gnome-hackers