| |
| |
| |
|
Page: 1 2 3
Comments:
<0> koen: http://bugs.openembedded.org/show_bug.cgi?id=1250
<1> koen: I'm a bit slow from the heat here... thanks
<2> it's at http://www.angstrom-distribution.org/unstable/images/20060729/poodle/ , but I'm pretty sure X will be pretty unstable
<1> ok, thanks
<3> koen org.oe.dev * r2ea49... / (3 files in 3 dirs): dbus 0.62: 'fix' segfault using patch from dbus 0.90
<4> I created a patch for that sdl.m4 problem. Is it enough to attach it to the bug report or should I mail it to someone / mailing list?
<1> goodnight
<3> pH5 org.oe.dev * rc1912994... / (16 files in 6 dirs): dbus, dbus-glib, dbus-python: update to 0.91/0.71
<5> does anyone know if there is a bb package that provides the switchto command for programatically switching vt's?
<6> emte, thx for answering me earlier - i was called away just after i posted that and havent been able to get back til now - so you are saying that a 5 min (bitbake -s) response is typical and theres no way to speed it up?
<6> anybody else who knows the answer, feel free to chime in here
<7> poushag: I think emte is right: 3000 .bb file to parse takes naturally quite many time. You may ask zecke to confirm it can not speed it up though
<6> well i think these files need to be hashed or put into a speedier db format or something - i have seen equivalent amounts of data parsed much more quickly
<8> poushag: IIRC, they're cached after they're parsed the first time
<8> Look under tmp/cache
<9> NAbyss: exactly, thank you
<6> yeah they are cached but it seems to only speed things up from 15 minutes to 5
<8> 5 mins? On what kind of hardware?
<8> Mine takes about 20 sec at most.
<9> poushag: then something's wrong
<6> mine has 512 mb of ram
<8> That's on an AMD running at 1466MHz..
<6> and i think a 2.something ghz p4
<8> poushag: Even at peak usage, python takes about 90mb on my box. I don't think RAM's going to be the problem
<6> well thats why im asking - i suspect something is wrong
<6> and i need help to figure out what it is
<8> It floats at about 50mb during parsing
<8> poushag: Local filesystem?
<6> checking...
<9> poushag: you shoudl eliminate the usual causes of slowness, like NFS, mounted sync, vfat fs, etc.
<8> poushag: I can understand being slow if it's NFS..
<6> ext3
<8> Also, run top.. see if anything else's stealing CPU.
<9> poushag: are you running root with an active chroot?
<6> im running bitbake as regular user
<9> hmmm
<6> the cpu seems pretty much idle
<8> poushag: Can you run 'time bitbake foo', and see if it's spent in system/user/io?
<6> ok
<7> here on AMD MP 1500+, ~15 secondes to parses the files/cache, ~2 minutes to get the output of 'bitbake -s'
<8> I'm no bitbake developer.. but I get the feeling the issue is with your setup rather than BB.. it shouldn't take 5 min on a 2GHz box
<6> its running - will prob be 5 minutes before i can post results
<6> real 3m39.261s; user 2m41.891s; sys 0m16.292s
<6> nabyss - i ran just 'bitbake -s' and posted the results
<10> poushag, i parse ~300files in 30 seconds
<10> let me shutdown some heavy apps
<6> ok - im still around
<10> ~790 in 15 seconds
<6> hit me by name though - im watching stargate atlantis on vlc :)
<6> oh youre ready now - nm
<10> it depends on what is active in your system
<10> the current bitbake is python centric
<6> the output i get says it pasrsed 3800 files in 15 secs
<10> so other apps can affect its performance
<6> but it didnt display all the text for another 6 minutes
<10> hmm
<6> do you understand the output of 'time bitbake -s' ?
<10> i didnt use time infront of mine
<10> sec i'll retry
<6> k
<10> usually i am doing enough other things i never notice
<10> real 1m28.507s
<10> user 1m26.507s
<10> sys 0m0.625s
<10> wasnt too bad
<6> how much ram on your system?
<10> 3GHz P4-E 2GB matched ram
<6> ok so yours should be faster since mines only 512mb
<10> not really
<10> your cpu being a 2Ghz and probably a cellery i suspect makes it slower
<6> well yours also has a fatter processor
<6> mines p4
<10> which chip?
<6> p4 2.8ghz
<10> 128 L1?
<11> this error log is from a fresh pull off 0z254x. http://pastebin.ca/106151
<10> 256, 512?
<10> arm-bar, you mean 354?
<6> but anyway its running inside a vm so theres a bit of a performance hit for that
<11> right
<11> *oz354x
<10> poushag, a bit?? i would expect a lot myself
<12> does anyone know how to get the state of the hinge sensor in the 2.6 kernel?
<10> event hardware emu have a large performance lag
<12> I know that zaurusd deals with the events, but I want to get the state for a sh script
<10> JustinP, i thought RP added a signal for that ...
<12> emte: not signal
<6> emte, im more concerned that oe is so slow on your system - i mean 3 minutes on your hardware (without vm, etc) is a lot of flops
<10> signal/event/callback etc
<12> emte: on resume I want to make sure the Z is open before the bl is restored
<12> emte: exactly. Not signal/event/callback
<6> it seems like it should be a lot faster
<12> emte: zaurusd can already do that
<10> poushag, its using python .... an interpreted language
<12> RP: I'd like to get the state of the hinge (from a shell script). Not on event (as zaurusd), just get the state.
<6> well it seems like this stuff should be hashed or compiled into binary files or something to speed it up
<10> JustinP, that doesnt fully make sense
<6> oh well i guess i will just live with it since im not enough of a guru to change it
<10> JustinP, for the shell script to run the event would have already occured and the backlight would be on ...
<10> poushag, it alrady is
<10> poushag, bitbake is more than 500X faster than it was
<10> it used to take 10-20min to parse the meta files initially
<10> and originally they were not even cached
<10> so you had to reparse everytime it erroerd out
<10> more speed enhancements probably wont happen until bitbake-ng
<10> anywya food time
<6> emte, sry not trying to offend anybody - i have not worked in many other dev environments - just trying to learn what to expect with this one - it still seems that 'bitabke -s' should be able to return output a lot faster than the other bitbake commands since its not actually building anything
<6> whats bitbake ng?
<6> nextgen i know
<6> but i havent heard that ng is in the works
<13> poushag: the first parse is slow, a couple minutes. subsequent runs are less than 15 seconds, since its cached.
<6> kergoth 'bitbake -s' runs faster the second time but is still six minutes
<13> it was planned long ago, but hasnt been touched in over a year. its more likely that components of bitbake will get moved to C one by one if need be
<13> then open a bug.
<13> whining on irc isnt going to do anything
<13> when doing actual builds, its less than 15 seconds for subsequent parses
<6> im not whining - just trying to figure out if it was only my system or if everyones
<13> so it must be something bound to -s
<6> well try it kergoth
<6> your comparative data can be useful here
<6> or run 'time bitbake -s' even
<6> to give a more detailed look
<13> first:
<13> real 3m14.674s
<13> user 2m54.940s
<13> sys 0m3.078s
<13> second:
<13> real 0m32.288s
<13> user 0m30.728s
<13> sys 0m0.217s
<13> and the vast majority of the second was processing after the parse
<14> hey kergoth
<13> the second finished the parse in like 3 seconds
<13> so clearly most of the work is whatever its doing to determine the providers that will be built
<13> hey chouimat
<6> so then your conclusion, kergoth, is that its behaving normally and no further optimization is required?
<10> hey chouimat , you try caos?
<10> i dont think that is what kergoth said
<6> thats why i was asking for his conclusion
<14> emte: nope ... got gentoo + local modification working on 4 computers ... 2 to go later next week
<13> no, that wasnt what i said at all. what i said earlier, and will continue to say, is that the caching of the parse works incredibly well, so your statements about desiring a cache are largely meaningless
<10> too bad
<13> it sounds like bitbake -s's processing beyond the parse could indeed use optimization in general
<14> emte: I know ...
<6> actually i never said i desired a cache - but in any case the gist is that i desire further optimization
<14> ok 8000 emails to go ...
<8> What does -s actually do?
<10> summary of versions i think
<8> Ah
Return to
#oe
or
Go to some related
logs:
#web
#ldap
iptables j jump back
mysqld-nt Got signal 11 Aborting
ubuntu second monitor
gnome no mode of that name
#sdl
#perl
mx3000 usb xorg
#linux
|
|