[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: Neural network placement policy, round II
From:       Nicolas Brodu <brodun () aston ! ac ! uk>
Date:       1999-12-20 15:04:49
[Download RAW message or body]

Cristian Tibirna wrote:

> Excellent
> 
> I've put a news item on our site (listing this among others).

:-)
 
> I'd do things a bit different, though:
> 
> - make the nnet an own object, and make it plug in the workspace manager
> on need (placement choice change).

Good idea. I just didn't investigate kwin enough to have it done already. But 
it's true the nnet object takes some memory...
BTW, kwin code is very clean, thanks!

> - put all the numbers in resetNeuralNetwork in the config file. This will
> make the code cleaner and would allow for future changes of the reset
> dataset without having to recompile.

That was the first idea. For some reason, KConfig of 29 nov 1999 corrupted
the neuralplacementrc file when called from the kwin constructor (?).
So for this pre-release I didn't check if it was working or not, and just 
used KGlobal::config() instead. Anyway, it's just a matter of changing a few 
lines of code, not a problem.

> 
> Did you thoroughly check the code? What happens kwin isn't configured to
> use neuralNet and then it tries to load or save the trained data? (Sorry,
> didn't have time to check the code now).

It loads them anyway in the constructor, and if they don't exist then they are
just 0 (and resetNeuralNetwork() is called). Saving only happens in
kwin destructor, as it took too long to save after each training.
I didn't check it more than this.

> You should make sure addition of neuralNet doesn't lower the performance
> of kwin (when using other placement than neural)  compared with kwin not
> containing the code. Sorry to insist so much on this. KWin is a central
> piece of the desktop and people were keeping whining that has performance
> issues even when it wasn't true.

Important point. I didn't run any benchmark or measurements of any kind.
Looking at the code, when neuralNet isn't chosen, there is:
- load() and save() in the constructor and destructor. Doesn't really matter.
- An if statement in doPlacement(). Neglectable.
- Some memory taken by the nnet object, since it's not pluggable.

I don't think (doesn't necessarily make it true, but...) this can cause any
performance problem. Moreover, even using nnet, I didn't notice any
speed issue.

IMO, the startup time for applications isn't due to kwin. Besides the point
it's well made, if you compile and run a simple X-Window program that does
nothing, liked just against Xlib, you'll see kwin _is_ fast...

If you prefer it though, I'll just commit in January after re-checking
everything. Otherwise, tonight.

Cheers,
Nicolas

-- 
A shortcut is the longest distance between two points. (unknown author)

[prev in list] [next in list] [prev in thread] [next in thread]