[haiku-development] Re: Latest changes and general status.
- From: Ingo Weinhold <ingo_weinhold@xxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Wed, 23 Apr 2008 17:51:44 +0200
On 2008-04-23 at 17:07:04 [+0200], Bruno Albuquerque <bga@xxxxxxxxxxxxx>
wrote:
> Bruno Albuquerque wrote:
>
> >> Well, I won't complain, I just have no clue, why. :-) BTW, do you
> >> build with -j4 or something?
> >
> > I was not doing that but I tried it again with -j4 and the performance
> > increase is mind blowing. But I remember that running with more than one
> > concurrent job eventually fails at the last steps (I don't remember
> > where exactly) due to what seems like a job being run that depends on
> > some other job that didn't finish yet. I will run it again at work (I
> > also have 4 cores here, but in 2 processors with 2 cores each) and will
> > let you known where it fails.
>
> So I did this in Linux and the difference is really impressive (I will
> also try it at home under Haiku). Also, the build did go through so I
> guess whatever problem I had at some point, doesn't seem to exist anymore.
If you mean #1976, that one does still exist. It's just not 100%
reproducible. It rarely happens on my machine, for instance.
> jam clean
>
> time jam -q
> [...]
> real 21m40.272s
> user 17m52.516s
> sys 3m35.016s
>
> jam clean
>
> time jam -j4 -q
> [...]
> real 5m32.583s
> user 11m9.594s
> sys 2m36.134s
>
> Note that these times include creating the image file and adding all the
> optional stuff to it.
The first run looks awfully slow. User and kernel time should actually be
pretty much the same as in the second run. If you started the second run
after the first one, the comparison is a little unfair, since a lot will be
cached already. Even taking this into account the first run is slow (note
that "jam clean" doesn't remove downloaded files, for instance).
CU, Ingo
Other related posts:
