akossh has quit [Remote host closed the connection]
mdz has quit [Ping timeout: 252 seconds]
xmn has joined #maemo-leste
joerg has quit [Ping timeout: 260 seconds]
joerg has joined #maemo-leste
xmn has quit [Read error: Connection reset by peer]
xmn has joined #maemo-leste
<freemangordon>
Wizzup: yes, with haze
<freemangordon>
weather app uses 70MB
<freemangordon>
so I am started to think this is qml
<freemangordon>
Wizzup: hmm, not sure if group chats do not work properly in 0.6, will checj
<freemangordon>
*check
<freemangordon>
arno11: how did you set-up the account?
<freemangordon>
I can confirm purple-facebook works properly though, in both pidgin and haze
<dsc_>
qml did not change much since few months
<freemangordon>
did we check the memory usage back then?
helslwed has quit [Ping timeout: 268 seconds]
<dsc_>
Wizzup has been monitoring it and claims it has onl recently increassed
<dsc_>
I also took some tests months ago but did not remember the values, but nothing out of the ordinary
<dsc_>
< freemangordon> weather app uses 70MB <== how much is conversations currently?
<freemangordon>
98
<dsc_>
iirc was always in this range, maybe even more
<dsc_>
but not a lot more
<freemangordon>
this is huge
<freemangordon>
mem usage shall be no more than 40MB
<freemangordon>
(lets say)
<freemangordon>
OMP, which is qt as well, uses ~50
<dsc_>
hmm
<freemangordon>
but conversations being resident all the time shall use less
<freemangordon>
so, my bet is on QML engine
<dsc_>
freemangordon: do you still have that hello-world example around? could you check that?
* freemangordon
checks
<freemangordon>
qml_hello uses 52MB
<freemangordon>
the other one uses 65
DaRiX has joined #maemo-leste
<freemangordon>
that's the one that uses QQuickWidget
arno11 has joined #maemo-leste
<freemangordon>
dsc_: ^^^
<dsc_>
there was a plan to decouple conversations such that a daemon is always running to register incoming messages, and the GUI be a seperate process that communicates with it
<dsc_>
this was resident mem is low
<dsc_>
this way*
<dsc_>
so that is one "solution"
<freemangordon>
no, we shall find a way to reduce mem usage to a sane value
<dsc_>
yes
<freemangordon>
like using qtwidgets
<dsc_>
and removing the QML?
<freemangordon>
instead of QQuickWidget
<freemangordon>
not sure
<freemangordon>
but we shall remove QQuickWidget at least
<freemangordon>
this one alone gives 15MB diff in sample apps
<dsc_>
hmm
<arno11>
freemangordon: i can confirm it worked once (with very last tp haze update) then, catastrophical after reboot
<freemangordon>
and is also not recommended by qt docs
<freemangordon>
arno11: ok, but please, explain what did you do
<freemangordon>
and what is catastrophical
<dsc_>
freemangordon: why do you think I made it via QQuickWidget
<freemangordon>
because I am looking into the code
<arno11>
fresh install, update to devel + FB plugin and ui
<dsc_>
so I can remove the widget when 10 windows are opened and only 1 is active ^^
<dsc_>
was a attempt at reducing mem footprint
<freemangordon>
see, I am not blaming you for qml being mem hungry :)
<freemangordon>
what I am saying is that we have an issue that shall be fixed
<dsc_>
yes :)
<freemangordon>
if theat measns that we shall remove qml, so be it
<freemangordon>
*means
<dsc_>
quite a lot of work went into that
<freemangordon>
sure, if you find other way, that's fine
<freemangordon>
but I am afraid there is no, given that simple sample app showing just a drawing takes 65MB
<dsc_>
we've had this interface for a while, only now I am receiving this constraint ^^
<freemangordon>
dsc_: how do you think, how usable is app that takes nearly half of the RAM?
<freemangordon>
also, I still don;t understand why do you take that personally
<arno11>
freemangordon: i think someone (other than me) must check what's going on from a fresh install
<freemangordon>
arno11: please elaborate on "catastrophical"
<freemangordon>
ok, I will check when I have time
<freemangordon>
but still, I see nothing obviously wrong with the latest changes that can result in catastrophe
<arno11>
i'm totally agree
<freemangordon>
so, please give me some details on what's going on
<freemangordon>
are you sure you start tp-haze properly?
<arno11>
yes
<freemangordon>
because if account is set to be online, then TP start it for you
<freemangordon>
and you cannot have 2 instances running
<arno11>
let me explain (a bit long)
<freemangordon>
ok
<dsc_>
I think for the n900 it is def. a problem
<dsc_>
for the d4 not so much
<dsc_>
I suggest a QtWidgets only version for n900
<arno11>
from a fresh install with devel upgrade and FB plugin and ui, it worked once...then after reboot i got some weird troubles like presence-ui disappering, some apps thinking there is no network, pidgin running @100% cpu, starting PA and python3 threads
<dsc_>
even if QML goes down to 50mb its still too much
<dsc_>
for something that ought to just render text chats...
<dsc_>
so, support to switch between QtWidgets/QtQuick
<dsc_>
im not removing the QML interface completely, ill let you know right now, someone else can do that
<dsc_>
technical implementation would be: 2 binaries that have different linkage
<dsc_>
< dsc_> im not removing the QML interface completely, ill let you know right now, someone else can do that <== what I mean is, if it is decided to get rid of the QML interface in favor of QtWidgets, I wont do that
<freemangordon>
dsc_: lets not take any decisions, it my turn out it can be optimized
<freemangordon>
arno11: I would bet you OC too much
uvos__ has joined #maemo-leste
<dsc_>
and for both cases, the daemon/client architecture could mitigate the remaining resident memory fears
<arno11>
no even with boost deativated, it doesn't work
<arno11>
and troubles start just after boot so overclock can't be involved
<uvos__>
we could also just have sphone be the default message ui for very memory constrained devices (n900 essentally)
<uvos__>
sure atm that comes with reduced feature set (no group chats, text only messaging) but its tiny
<uvos__>
and i will have to maintain sphones message ui anyhow since i use it oustide of maemo
<uvos__>
i think trying to reduce the memory usage of qml is a fools errand
<freemangordon>
arno11: no idea what's going on with your device, but I can assure you it is not related to fb plugin
<freemangordon>
so, if I were you, I would flash new image, install whatever needed and do not OC until proven stable
<freemangordon>
then I would OC to 720 and keep it like that for a week or so
<freemangordon>
then to 805
<freemangordon>
and no more
<arno11>
freemangordon: again, overclock is not in use...
<uvos__>
i used to run my droid 1 (also omap3) at 1050MHz
<uvos__>
:P
<freemangordon>
but, did you OC before it broke?
<arno11>
overclock can't work on boot
<uvos__>
1ghz wasent usual on those
<uvos__>
*unusual
<freemangordon>
yeah, there are some samples of n900 that were reported to run at 950
<freemangordon>
no idea how stable and for how long :)
<uvos__>
arno11: well one thing is that if you over oc you get memory corruption, which can end up as disk corruption
<freemangordon>
arno11: did you run the device OCed even for a while?
<freemangordon>
exactly
<uvos__>
so you might be hosed even after removeing oc
<freemangordon>
right
<freemangordon>
arno11: and given that you flashed new image because your old one had similar symptoms, I would say it it the OC to blame
<freemangordon>
and you should not push to 850
<arno11>
i use 805 max
<freemangordon>
the same applies
<freemangordon>
even that is high
<freemangordon>
could you run fsck on the fs?
<freemangordon>
thoug, it might show noting
<uvos__>
time for btrfs xD
<freemangordon>
:)
<uvos__>
might actually be a good way to check a oc long term
<freemangordon>
arno11: really, I would recommend to start from scratch and *do not* enable OC
<freemangordon>
that way if you hit the same issue, we will know it is not OC to blame
<arno11>
ok but i'm writing from the device and got no time to answer to all stuff...
<freemangordon>
I just rebooted my d4, which uses exactly the same fb/haze as your n900
<freemangordon>
and it has absolutely no issue whatsoever
<dsc_>
its a branch with all qml removed, but rtcom/TP still working
<dsc_>
so could check the difference between with/without QML there
<dsc_>
cmake -DCMAKE_BUILD_TYPE=Release -Bbuild .
<dsc_>
make -Cbuild -j4 conversations-tiny
<dsc_>
./build/bin/conversations-tiny
<Wizzup>
dsc_: I get:
<Wizzup>
/home/user/conversations/src/chatwindow.cpp:69:20: error: ‘class Ui::ChatWindow’ has no member named ‘quick’ 69 | auto *qctx = ui->quick->rootContext();
<dsc_>
Wizzup: make -Cbuild -j4 conversations-tiny
<Wizzup>
ok
<Wizzup>
it does save some ram
<Wizzup>
max heap usage for just the first5 seconds is about 100MB without and 168MB with
pere has quit [Ping timeout: 255 seconds]
<Wizzup>
but I am not sure if we need to care at this point
elastic_dog has quit [Ping timeout: 260 seconds]
<Wizzup>
rtcom-messaging-ui on fremantle uses 6.7% memory on the n900 with some windows open, conversations is 17% on the n900 atm, QML is maybe half of that
<Wizzup>
there is still plenty of ram available on the n900 too
elastic_dog has joined #maemo-leste
<dsc_>
still, its quite easy for me to make something switch between QtWidgets/QtQuick
<dsc_>
by having 2 binaries
<dsc_>
so that option is available
<Wizzup>
I think we stay the course for now but keep this in mind
<Wizzup>
there's still the other 60% of memory that goes to non-qml things
<Wizzup>
I'd rather have a fully functional conversations with no memleaks and qml than nothing
<dsc_>
:)
<Wizzup>
also splitting things out in two binaries at this point is also not a good idea, we're still figuring out how to it fully pt aware
<Wizzup>
s/pt/tp/
<dsc_>
no I meant we'd have `conversations` and `conversations-tiny`, the latter would omit linkage against Quick
<dsc_>
what you just ran does not link against quick
<dsc_>
so I only need to add a QTextBox for the chat
<dsc_>
etc.
<Wizzup>
I mean, you can if you want to toy with it
<dsc_>
above PR is like 70% of that hehe
<dsc_>
and via `cmake -> make` it would generate those 2 targets
<dsc_>
anyway I rather look into room registration right now
<Wizzup>
I think both are fine yes
<Wizzup>
wrt room registration, we'll have to join on various times from tp (reconnect due to network, or when the account is first online)
<Wizzup>
and I would use the local_uid as key
<dsc_>
alright
<Wizzup>
and we might want to offer some interface to get the current channels from the tp account class
<Wizzup>
osso-addressbook uses 12.1% ram on n900 btw (compared to 10.3 conversations atm)
<Wizzup>
plus, most of qml might just be shared with other qml apps
<Wizzup>
they are talking to themselves there I think
arno11 has joined #maemo-leste
<arno11>
freemangordon: overclock is not involved, still the same issue, but doing expandcard then reboot, dist-upgrade then reboot, extras installing stuff then reboot, setting up an account with pidgin works (works in every cases with bitlbee and bitlbee-FB), with almost no cpu usage
<Wizzup>
freemangordon: whatever empathy does to read purple vars, it doesn't use dbus
<arno11>
purple-facebook refuses to connect and presence-ui doesn't work
<arno11>
maybe that's just an issue with my account btw
<Wizzup>
freemangordon: seems to deal with a tmp file /var/tmp/haze-59dFiV/accounts.xml
<freemangordon>
Wizzup: sorry, I am missing the context
<freemangordon>
arno11: please, please, try to not use "does not work" etc, explain what does not work instead
<freemangordon>
does purple-fb work through pidgin?
<freemangordon>
if it does not, then there is no point to test it with presence-ui, accounts-ui, conversation s, empathy etc
<Wizzup>
freemangordon: I am trying to understand how empathy gets the purple-specific settings through haze
<freemangordon>
ah
<freemangordon>
they are visible through tp interfaces
<Wizzup>
weird, I did dbus-montor
<Wizzup>
monitor
<Wizzup>
grepped for it with empathy running
<freemangordon>
sec, lemme try to find it
<Wizzup>
nothing matched the key names
<freemangordon>
yes, they register pidgin properties as connection/protocol properties
<Wizzup>
btw, in empathy I now see a channel with the new haze code in slack
<Wizzup>
but the messages come in as HandleTypeContact
<arno11>
freemangordon: ?? as previoulsy mentioned, pidgin works well with purple-FB, and purple-FB + FB UI refuses to connect (with presence UI not working/displaying)
<freemangordon>
Wizzup: yes, how should they come? Like, how do you know who wrote?
<Wizzup>
freemangordon: they are part of a TextChannel that is a room
<freemangordon>
wait
<freemangordon>
how do you know who exactly typed that particular message?
<freemangordon>
if we are 3 peuple in a chat
<freemangordon>
*people
<freemangordon>
for example
<Wizzup>
freemangordon: message.sender()->id()
<freemangordon>
if message handle is the room handle, how do you know which of the 3 typed that message?
<Wizzup>
that is not the same as the channel->targetHandleType()
<freemangordon>
what is message?
<Wizzup>
any incoming message
<freemangordon>
sac
<Wizzup>
the channel facilitates the sending and receiving of messages, and the message itself contains who sends it
<Wizzup>
the channel reports if it is a single 1:1 or room (multi user) channel
<Wizzup>
it looks like in this case in haze this is not correct yet, BUT
<Wizzup>
somehow empathy gets it ok
<Wizzup>
maybe it looks at the supported interfaces
<uvos>
we mesured this in detail before with the script that devides for shared memory regions and accounts for xorg surfaces
<uvos>
its essentally nothing
sixwheeledbeast has joined #maemo-leste
<freemangordon>
uvos: how much memory does it take for all the sybols resolution and gtk/pango/cairo statically allocated data?
<freemangordon>
*symbols
<uvos>
i dont know it in that detail
<uvos>
but the way we mesured it was takeing private memory, adding the shared memory regions per region devided by the number of procesies that map that region
<uvos>
and then adding the increase in memory usage of maemo-launcher that is incured when launching the app
<uvos>
the last part is the vast majoraty of the memory usage in the launcher case
<uvos>
because somhow launcher ends up with most of the allocations for some reason
<uvos>
not sure how that works
<uvos>
in the non launcher case you do the same, just no launcher obv
<uvos>
i did this back when .launches where binaries not shared lib
<uvos>
so you could execute them directly
<freemangordon>
so, how would you explain the pastebin ^^^
<freemangordon>
I did that several times
<uvos>
wel i cant see it
<uvos>
its not available
<freemangordon>
oh, sorry
<freemangordon>
12022 user 20 0 137524 42216 35772 S 0.0 4.1 0:01.55 qttest .launcher
<freemangordon>
12081 user 20 0 136384 43324 36964 S 3.9 4.3 0:01.00 qttest normal
<freemangordon>
43324 vs 42216
<uvos>
launcher changes accounting
<freemangordon>
this is a simple application with one push button
<uvos>
you will note that the launcher will end up with more memory used after the launch
<freemangordon>
launcher just forks and calls main()
<freemangordon>
I don't see how would that increase any memory of the daemon
<uvos>
it dose for gtk programs, its possible it dosnt here because that happens because of somehting the booster dose
<freemangordon>
booster does nothing for qt (still)
<freemangordon>
but qt also uses gtk and pango and cairo (via gtk)
<freemangordon>
so all the data thise FW allocate an process startup is savesd
<uvos>
anyhow its using more shared memory
<freemangordon>
ald the glib objects etc
<uvos>
which is probubly meaningless
<freemangordon>
just imagine how much we save from not creating glib object classes
<freemangordon>
I would argue
<uvos>
well i did this mesurement in high detail on osso-xterm and came up with about 100kb
<Wizzup>
wasn't it more about startup speed than memory saving?
<uvos>
Wizzup: no it saves no speed
<uvos>
i also did that mesurement
<uvos>
that one is still on github
<uvos>
it saves no speed over the readahead replay case
<uvos>
on d4
<uvos>
but it dose decrease cpu usage some, but launching is io bound so it ends up a tie in terms of speed
<uvos>
also it causes the libs to be in memory allready on first launch
<uvos>
so first launch is faster if you dont have something like systemd-readahead
<freemangordon>
then your measurements are broken, because it saves all the symbols resolution
<freemangordon>
because libs are already there, with symbols resolved
<uvos>
saveing symbols resolution is the reason why it takes less cpu time
<uvos>
but this has no effect on launch speed
<freemangordon>
how's that?
<uvos>
because the whole process is io bound
<uvos>
the cpu _is_ more busy but the if you go gtk_init(); return 0; in main the launcher and non launcher process will end up exiting within mesurement error time wise
<uvos>
but the non launcher process will have kept the cpu more busy
<uvos>
i gues this may not be true on n900 since the io is the same speed but the cpu is slower
<uvos>
anyhow launcher dose help here since we dont have systemd to help us and i keeps all the often used libs in ram
<freemangordon>
doing simply gtk_init() is not the usual case
<freemangordon>
usually you create lots of glib classes
<freemangordon>
and this is where it makes the difference
<freemangordon>
because the static memory is already allocated
<freemangordon>
by static I mean it is heap mamory but allocated only once per process lifetime
<uvos>
well the intention was to make symbol resolution the main part of the execution time
<Wizzup>
did we ever try ksm?
<freemangordon>
also, all the so symbols are resolved only once
<Wizzup>
or did this incur pm hit?
<uvos>
to maximise the launcher efect
<uvos>
Wizzup: i did
<uvos>
Wizzup: it helps some
<uvos>
dont remember the numbers
<uvos>
but maybe a couple meg on d4 at the expense of a lot of cpu time
<Wizzup>
seems worth doing in any case
<Wizzup>
hmm
<uvos>
n900 cant do it imo
<Wizzup>
a lot of cpu time?
<uvos>
yeah so theres 2 problems with this
<uvos>
i started it on boot and then stoped it after it was done with a pass, it takes a huge amount of cpu time just after boot while its doing its thing (pegging one core)
<uvos>
and it only helps with stuff launched while its active
<uvos>
it could be used on d4 since you have another core to service the user
<uvos>
but on n900 its going to suck
<uvos>
and a pass takes like 10 minutes
<uvos>
so in the end i dont think its usefull atm
<uvos>
since d4 has no problems with ram anyhoiw
<uvos>
anyhow so my over arching point is that yes maemo launcher helps some, but most of the ram is shared allready so it only helps a little, and you have to take into account the amount of ram used by the launcher itself devided by the launch procesies
<uvos>
also for speed it helps not very mutch besides being effectively a good disk catch (which is nothing to sneeze at) and maybe a bit more on devices with fast io realtive to cpu (n900)
<uvos>
but it aint magic
<uvos>
*cache
<freemangordon>
sure it is no magic
<freemangordon>
but it is not useless as well
<uvos>
i never said its useless, i have questioned the matiniance burde to usefullness ratio in the past (esp problems with glibc) but not the absoult merit. and besides as long as i dont have to maintain it i dont care mutch
<uvos>
also since qt internals change pretty rapidly i question the wisdom of trying to hack around in those internels with a boost module, but if you want to keep up with that, thats fine.
<freemangordon>
at least we can try
<uvos>
sure
<freemangordon>
like, having QApplication ang QWidget loaded byt the booster
<uvos>
sure yeah, also maybe qt has some special proparties that make it mutch more sutable to having more stuff in shm than gtk2 is
<uvos>
i have no idea
<Wizzup>
uvos: wrt ksm using a lot of cpu, was it something that could be tweaked?
<uvos>
i mean not really
<uvos>
fundamentally it needs to compute a hash of every page
<uvos>
thats very expensive no matter how you cut it
uvos__ has quit [Ping timeout: 264 seconds]
<Wizzup>
uvos: right, but if it runs every 15 mins or so
<Wizzup>
freemangordon: changing the _ to - makes it work
<Wizzup>
ty
<Wizzup>
freemangordon: btw you're saying that for facebook you're getting the messages you write elsewhere reported to tp?
<Wizzup>
say if you write it on some web client or so
<Wizzup>
freemangordon: also, for the slack purple plugin one can provide either a password or api-token, but I don't really know how to do this wrt rtcom ui
<Wizzup>
I suppose I could remove the password cap and then have password and api-token in teh advanced page
<Wizzup>
cool, have icons now too in slack :p
<Wizzup>
sicelo: uvos: when you mean gpu hang, do you mean device reset, or?
<uvos>
Wizzup: no its the never returing ioctl thing - or at least the symptoms are the same
<uvos>
the device fails to render any new frames, the last frame is displayed forever but the kernel is alive enough to never trigger a wdr