Mailinglist Archive: opensuse (3263 mails)
|< Previous||Next >|
Beagle performance: end-user problem? (was Re: [opensuse] Beagle under 10.3 is really eating up my CPU)
- From: Linda Walsh <suse@xxxxxxxxx>
- Date: Sat, 22 Dec 2007 16:29:04 -0800
- Message-id: <476DABD0.3020405@xxxxxxxxx>
---.The Saturday 2007-12-22 at 16:06 +0100, Anders Johansson wrote:
The real solution here is to find and fix the bug that causes beagle to
allocate so much memory. It doesn't happen on all systems.
Without question, this is the best solution.
Anders Johansson wrote:
I wouldn't say "probably". It shouldn't be par for the course for an application to not check return values from memory allocation functions
Aaron Kulkis wrote:
As I said earlier... the whole thing is poorly written.---
And you say this based on??? Do you have _any_ expertise
in the source? (if you do, sorry, but your attitude is not
productive). It _appears_ you know nothing about how it is
written but are basing your opinion on its behavior in certain
This is why I made a comment about *not* using "swap"
on a system -- if you are using swap on any regular basis (my
threshhold is using swap, *anytime*, during 'normal' day-to-day
usage), you are running applications that are "too big" for for
your machine. Now whether this is due to poor application memory
usage OR is due to poor-planning on the part of the system owner
depends, in large part, on promises or expectations set by the
developer or owner of the program.
Certainly, if I am running on a system with 128M of memory
with a 650MHz mobile CPU, and load a full "suse 10.x" desktop with
full features, I am asking that I be "shot in the foot". If
a release (like suse10.2, or windows 98) says it will run best with
1GB-mem + a 1GHz processor and my machine has 2GB+a 2GHz processor
and the release runs like a "dog" -- then I'd say it is the fault
of the release packager (they made the choice of what packages to
include 'by default').
Certainly if the *end user* chooses to run more applications
than their computer can comfortably fit in memory, how can the
application developer account for this.
Beagle should be scrapped and started over from the-----
ground up, starting with the design assumption that it
is to behave as an unobtrusive background process, not
the current one which can take over the whole system
with a "feed me" attitude as if the whole purpose for
a computer and its data to even exist is to provide
something for a beagle process to index.
Do you have documentation or direct knowledge
of what the "design goals" were? If not, how do you know it
wasn't designed that way?
Something the beagle developers cannot know is how
their application will be installed by release packagers. One
example of an outstanding 'bug' (or feature depending on
interpretation) that can affect beagle performance
is how it is run by 'cron.daily'. From my own experience,
under 9.3, the default is to run cron.daily 24 hours after it last
ran -- but if something delays it running "overnight" (like the
machine being off or suspended) it will run within 15 minutes
of the machine becoming active. IT WON'T WAIT until the
'middle of the night', as you might want. This has nothing
to do with beagle or its developers.
Ideally, the beagle indexing process would run once
(either at night, or immediately if needed), and then be able
to monitor the filesystems and directories for changes using
the "fam" (famd) package.
The "fam" function (and as extended for directories
and/or devices) monitors when any change is done to its monitored
file-system objects, then calls "listening" programs to process
the new or changed objects as they are changed on disk. Ideally,
you would then need no 'batch' updating, but such would be done
in "bits" throughout the day as monitored files are changed.
That being said, if a system doesn't have the OS support
or resources needed to run 'famd' without without degradation, the
system will still be painful to use (shorthand: "be unusable").
Be careful about "global generalization" about a product
being bad, though, though, just because it doesn't run well in
a particular situation.
To unsubscribe, e-mail: opensuse+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse+help@xxxxxxxxxxxx
|< Previous||Next >|