mozilla :: #content

11 Jul 2017
00:11bkellymystor: jdm: do you guys know if there is some chrome script that accesses cookie service on a 3 second timer?
00:11mystorbkelly: I hope not, why do you ask?
00:11jdmbkelly: my instinct would be to look at the session cookie stuff, but otherwise no
00:12bkellyI'm trying to figure out where some of this "idle" cpu usage in content scripts is coming from...
00:12bkellyI see chrome script hitting cookie service every few seconds in this profile:
00:12bkellymystor: jdm: ^^^
00:12bkellybut the xul name is hidden
00:13* jdm does not see that
00:13bkellyjdm: you don't see it in that profile?
00:13bkellyor on your machine
00:14jdmbkelly: the profile only spans .5s as far as I can tell, and the link did not take me to a call stack that involved the cookie service
00:14bkellyjdm: is it showing you a zoomed in time range?
00:14jdmoh, I guess so
00:14bkellyhow about this one:
00:16jdmchrome code calling document.cookie is super weird
00:16jdmbkelly: addon?
00:16bkellyjdm: the only addon I have is the profiler
00:19mystorI don't see any references to document.cookie in tree
00:19mystor(that is, in chrome code)
00:21mystorbkelly: How do you know the caller is chrome?
00:21mystorbkelly: On at least one of the processes it's being called by code
00:21bkellymystor: the first function out of the DOM timeout code is shown as: <name omitted>
00:22bkellymystor: it says &quot;<name omitted> XUL&quot;... I assumed that was browser chrome
00:22mystorbkelly: the XUL means its a function from libxul
00:22mystorXUL is in a lighter color which means its the name of the static lib it&#39;s fro
00:22mystorbkelly: I think your culprit is content
00:23bkellymystor: why would the name be omitted?
00:23mystorbkelly: I&#39;m guessing the frame just doesn&#39;t have an associated symbol in the binary
00:24mystorbkelly: As in, it&#39;s a function from libxul which we don&#39;t have the symbols for :-/
00:24bkellylet me try closing my various content tabs
00:26bkellymystor: ok, you are right
00:27mystorbkelly: glad I could help
00:27bkellysadly I already filed a bug
00:28bkellyok, here is a profile with just 4 tabs open:
00:28bkellywe still are doing something from timers
00:31bkellylooks like some image cache interval timer
00:32bkellyand the profiler itself
00:38bkellyso I guess its fine
12:09smaugemilio: Do you know how much very low level rust code has been written and how it compares to C++ in performance
12:45emiliosmaug: hmm... I know there are kernels, embedded stuff, etc, written in rust, but not sure how it compares in performance...
12:45emiliosmaug: for user-space low-level code, I guess or such is a good example, but I guess not all is language-dependent
12:46emiliosmaug: theoretically rust allows betters optimization than C++, not sure whether all of them are implemented
12:46emiliosmaug: but I&#39;m fairly confident that you can get same or better perf than C++
13:02smaugemilio: I guess I&#39;m mostly interested in how likely it is to write very well performing rust code
13:03smaugemilio: or whether there are, for example, commonly used patterns which are malloc heavy
13:04* smaug is just randomly thinking about possible issues using more rust could bring
13:05emiliosmaug: if you have experience, very likely, but I&#39;ve seen beginners passing Vec<Foo> or Strings by value cloning them around... But that&#39;s just the same as a c++ beginner passing vector<T> or strings by value...
13:05smaugemilio: well, also things like implementation of Vec
13:06smaugI saw some bug related to vec and stylo causing lots of malloc usage
13:06smaugand that smelled like not so well fitting vec impl
13:07smaug(which is a reason why Gecko doesn&#39;t use stl APIs too often, but better fitting impls of common datastructures)
13:07emiliosmaug: that&#39;s a Gecko allocator issue on Mac, we just happened to notice it while profiling stylo :)
13:07smaugemilio: is that allocator issue, or vec usage issue?
13:07smaugor both?
13:09emiliosmaug: In this case there really isn&#39;t a better data-structure than Vec for what we&#39;re doing (building a list of Rule objects that is going to be mostly static and iterated in order), so I&#39;d say just allocator issue in this case
13:09emiliosmaug: is what you saw, right?
13:09firebotBug 1360772 FIXED, stylo: Lots of time spend in bzero when doubling vecs
13:09smaugI think so
13:10smaugemilio: well, Gecko tries to not use vector, but nsTArray since nsTArray has better malloc usage for many cases
13:10emiliosmaug: how do they differ?
13:10emiliosmaug: The other thing I can think of, is that by default the rust hashmap hashing functions are slow (they use siphash)... But on top of that I can&#39;t think of any other footgun
13:10smaugemilio: IIRC nsTArray increases its internal size faster
13:11emiliosmaug: I see, well, I guess it depends on the implementation of vector<>, but yeah, having control over that seems worth it to have predictable perf
13:11emiliosmaug: good that in rust at least there aren&#39;t multiple stdlibs :)
13:15smaugemilio: another rust related question. That patch you provided yesterday or so (thanks!), why do we need to do that. Do we really not have sane bindings for calling C++ from Rust?
13:16emiliosmaug: we do, but for stuff that we check all the time, we try to avoid a ool function call if possible
13:16emiliosmaug: it&#39;d be a shame to do a function call to get, for example, the parent node
13:17smaugoh, the bindings are slow?
13:17smaugwhy we don&#39;t have better bindings?
13:17smaugI&#39;m thinking about maintenance here now
13:18emiliosmaug: they&#39;re not slow, but they have an imposed cost of a function call
13:18emiliosmaug: basically, the way to go C++ -> rust or vice versa is either an extern &quot;C&quot; function call, or poking directly at the C++ object (which implies writing the accessors in rust)
13:19smaugsince Gecko gets more and more Rust code, and we need to optimize performance everywhere, maintenance and performance are among the top things to work well
13:20emiliosmaug: extern &quot;C&quot; works fine (it&#39;s just a normal call, no other overhead), except for stuff that is super-hot, which we optimize rewriting the accessor in rust.
13:22smaugemilio: extern C setup doesn&#39;t inline the function or what?
13:23emiliosmaug: no, because there&#39;s no LTO across languages (that&#39;s fixable for clang + rustc, but not so sure about MSVC)
13:23emilioor gcc for that matter
13:38smaugemilio: feel free to correct me on dev.platform :)
14:41firebotBug 1379973 UNCONFIRMED, Web Push notifications not triggered in service worker with e10s
17:19mystorIf I need a TArray in static storage, do we have a better option than UniquePtr<nsTArray<Foo>> with ClearOnShutdown() being called on the UniquePtr?
17:19mystorThat seems unfortunate to me as we then have to chase 2 pointers from static storage to get to the TArray (not that this code is particularialy performance sensitive)
17:23mystorsmaug: ^
17:25smaugI don&#39;t think we have anything better. AutoTArray might work there too, if you have just couple of entries usually
17:25mystorsmaug: I just don&#39;t want to be deleting the array elements in the static destructor, and would prefer to instead delete them in ClearOnShutdown
17:26mystorsmaug: I think I&#39;ll just do that for now
17:26mystor(the UniquePtr thing)
17:26mystorIt&#39;s super gross though
18:04bkellybaku|away: are the streams patched stable enough for review?
18:05qDotbz: So, I&#39;ve got the applet tag removal bug done, but looks like you&#39;re not taking reviews. Who else around here do we trust for something like this? :)
18:06bzqdot: I&#39;m going to reopen my review queue later today or worst-case tomorrow
18:06* bz was on vacation, is still catching up
18:06bzqdot: so you can just needinfo me if you want
18:06qDotbz: Awesome. I&#39;ll get in line. This is better than waiting for an iphone!
18:07bzbkelly: do you have a sec?
18:10bkellybz: sure
18:10bkellybz: although if this contractor calls I will have to go yell at him
18:11bzbkelly: I&#39;m having a weird serviceworker problem withe perf.html
18:11bzbkelly: backlog for #developers has data, but basically for I&#39;m in a state where the service worker seems to be replying with corrupted content to various requests...
18:11bkellybz: can you define &quot;weird&quot;?
18:12bzbkelly: in the &quot;I get a Firefox error page about corrupted content&quot;
18:12bzbkelly: So first question: how can I see the source of the service worker being used?
18:13bkellybz: in about:debugging
18:13* bz clicks &quot;opt out of multiple content processes&quot;
18:13bkellybz: that will restart your browser
18:13bkellyto take effect
18:14bzlet&#39;s take this to #developers
18:56bzI can do that
18:56bzer, wrong window
19:47emiliosmaug: do you think it&#39;d be worth it store the primary frame of an element in the slots, and use union { nsDOMSlots*, nsIFrame* } to save a word?
19:49smaugemilio: no
19:50smaugemilio: primary frame is needed way too often
19:50smaugand most of the DOM elements have primary frame
19:50emiliosmaug: I guess that&#39;s true...
19:50smaugemilio: and it is already union
19:50smaugprimary frame or subtree root
19:53emiliosmaug: huh, true that...
19:53smaugemilio: FWIW, right now very commonly used elements have quite good size, 128 bytes on 64bit
19:53emiliosmaug: so the subtree root is only used when detached from the doc? I guess that makes sense
19:53smaugyeah, since when in tree, OwnerDoc() can be returned
19:54smaugat least in non-shadow dom
19:54emiliosmaug: I see, ok then, just thought about it and was curious about what were your thoughts on that, but those are good points
20:43mystorsmaug: Do you happen to know if it&#39;s possible to get a nsCString without a null terminator?
20:43mystorsmaug: IIRC it is
20:43mystor(but unlikely or something like that?)
20:44mccr8the string guide says &quot;The string classes distinguish, as part of the type hierarchy, between strings that must have a null-terminator at the end of their buffer (ns[C]String) and strings that are not required to have a null-terminator (nsA[C]String).&quot; FWIW
20:46smaugand PromiseFlatString can be then used when really needed
20:48bkellyhmm... &quot;MozReview and Splinter turned off in early December.&quot;
20:53smaugand we&#39;ll all use the raw patch for reviewing :)
20:53smaug&quot;details&quot; link
21:03bkellysmaug: you have a more positive attitude than I do... I was leaning more towards the sulky &quot;well, fine, I just won&#39;t review then!&quot;
21:04smaugbkelly: well, I prefer reviewing raw patches
21:05bkellysmaug: I suppose I can self host a splinter instance
21:31smaugerm, our textnode text handling is rather malloc heavy
21:50smaugnsGenericDOMDataNode::SetData seems to usually get a string backed by a string buffer, but we don&#39;t use that at all
12 Jul 2017
No messages
Last message: 74 days and 21 hours ago