SystemDependentDataBuffer bits ...

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Armin,

	I guess you missed the appended on IRC.

	It seems odd that just typing in writer should be so rapidly creating
and destroying these cached items. A couple of thoughts:

	* do we need to do this for simple / common polylines etc. ?
		+ surely there is a complexity/benefit tradeoff here.

	* should we not disable the SystemDependentDataBuffer ie.
	  remove:

                if(maEntries.empty() && maTimer)
                    maTimer->Stop();

	  from there we can stop ourselves in the timeout if necessary.

	  this can save us doing a chunk of un-necesary scheduler work
	  which can be rather expensive.

	Noel any chance of killing those lines & testing ?

	Armin - any thoughts on whether this is truly necessary for
	simple polylines ? (is it to cache the winding / self
	intersection stuff ? )

	Thoughts ?

		Michael.

<mmeeks> caolan, alg: I wonder if you see a lot of:
<mmeeks> info:vcl.schedule:4742:4748:vcl/source/app/scheduler.cxx:588:
1556195258227 0x7f0124085af0  restarted  a: 1 p: 1 vcl
SystemDependentDataBuffer aSystemDependentDataBuffer
<mmeeks> info:vcl.schedule:4742:4748:vcl/source/app/scheduler.cxx:596:
1556195258227 0x7f0124085af0  stopped    a: 1 p: 1 vcl
SystemDependentDataBuffer aSystemDependentDataBuffer
<mmeeks> caolan: if you run with
SAL_LOG="+INFO.vcl.schedule+WARN.vcl.schedule"
<vmiklos> mmeeks: yes, it fies every second, see
vcl/source/app/svdata.cxx:121
<vmiklos> fires
<mmeeks> caolan: looks to me like we're doing heavy-lifting to cache
even the cairo paths for the most banal polypolygons we render - (just
typing randomly in writer) - which hits all sorts of locking there, as
well as hitting the scheduler core too.
<mmeeks> vmiklos: sure - but I get ~hundred of those rendering a tile ;-)
<mmeeks> vmiklos: we seem to add and remove it a -lot- which seems
rather unreasonable - but perhaps it's just noisy debuug
<vmiklos> ah
<noelgrandin> oddd I thought that that SystemDependantDataBuffer stuff
was only for caching drawing operations for drawinglayer/etc, would not
have expected it to fire in writer
<mmeeks> vmiklos: ~150k of those while typing ~3 lines of random text in
writer =)
<mmeeks> noelgrandin: might be worth a chase ? =) I suspect we're doing
it for banal polypolygons =)
<mmeeks> and we shouldn't - start/stop/copy/allocate is expensive
<noelgrandin> oh great, debugging SystemDependentDataBuffer::startUsage
crashes gdb
<caolan> mmeeks, I don't know anything about that relatively new caching
stuff, except that it seems to be the reason tdf#124863 doesn't work anymore

-- 
michael.meeks@xxxxxxxxxxxxx <><, GM Collabora Productivity
Hangout: mejmeeks@xxxxxxxxx, Skype: mmeeks
(M) +44 7795 666 147 - timezone usually UK / Europe
_______________________________________________
LibreOffice mailing list
LibreOffice@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/libreoffice




[Index of Archives]     [LARTC]     [Bugtraq]     [Yosemite Forum]     [Photo]

  Powered by Linux