[00:00.000 --> 00:11.160]  Hello everybody. Thanks for being here. I'm so glad to be here for them. That's the first
[00:11.160 --> 00:18.400]  time in three years it's we're in person. So yeah, I'm so glad. So I'm Julien. I work
[00:18.400 --> 00:24.600]  at Mozilla for like 10 years now and so you can find me on mastodon, you can find me on
[00:24.600 --> 00:31.600]  Twitter, you can find me on Matrix, you can find me in Paris. And of course, so Mozilla
[00:31.600 --> 00:38.720]  you know that so well. We are responsible for Firefox. It's high performance, open-source,
[00:38.720 --> 00:44.800]  privacy-conscious. So I'm sure you already have it on desktop, you'll have it on your
[00:44.800 --> 00:52.360]  phone. So you link them together and use your history and your password. You know that already.
[00:52.360 --> 01:01.400]  Mozilla is also famous for the MGM of course, for all your development fantasies. And for
[01:01.400 --> 01:05.640]  VPN and for Firefox monitor, a lot of good stuff. But today I want to talk about the
[01:05.640 --> 01:12.240]  Firefox Profiler. So you can find this slide here and with the QR code as well. And let's
[01:12.240 --> 01:21.000]  dive in. So this is the thing I want you to leave the room with today. First, I want you
[01:21.040 --> 01:26.160]  to know what a Profiler is. I want you to know how you capture and how you can share
[01:26.160 --> 01:29.240]  a profile. How you can share a profile with your colleagues, but also how you can share
[01:29.240 --> 01:35.320]  a profile with us Mozilla in case you have performance problems with Firefox. And finally,
[01:35.320 --> 01:39.600]  we will do a quick tour of the UI so that you can have the first glance of how you can
[01:39.600 --> 01:47.400]  analyze a profile. So first, the Firefox Profiler, at least the UI, it's just a web app. It's
[01:47.400 --> 01:52.800]  a React-based web app with no privilege at all. It's used as a service worker so that
[01:52.800 --> 01:59.160]  it works offline. And it's also an open source project. You can find it on GitHub. You can
[01:59.160 --> 02:05.040]  do contributions. You can look at the source code. You can even adapt it for your needs.
[02:05.040 --> 02:15.640]  So yeah, come and do some React-based contribution with us. So first, what is a Profiler? So
[02:16.360 --> 02:24.520]  I was scared by this cat because it's so big here. So yeah, how do you measure
[02:24.520 --> 02:30.680]  prep performance? You can measure it on three different places, basically. You can measure
[02:30.680 --> 02:39.800]  it locally on your computer. You can measure on the CI with automated tests and benchmarks.
[02:39.800 --> 02:45.120]  And you can measure on your user's computer. This is called real user monitor. But there
[02:45.120 --> 02:50.800]  are also different timings characteristic, right? Locally, you get the results right away.
[02:50.800 --> 02:55.000]  You profile, you look at it, you get a measure. On the CI, you can get the result after maybe
[02:55.000 --> 03:01.600]  one hour. And with the real user monitor, of course, that takes a few days. And the
[03:01.600 --> 03:07.280]  Profiler, this is locally. So this has some advantages. Of course, you get the result right
[03:07.280 --> 03:13.520]  away. But this also has some drawbacks that we dive into later. So basically, this is
[03:13.600 --> 03:19.480]  a tool. This is just a tool in your toolbox, right? This helps you analyze performance
[03:19.480 --> 03:24.520]  issues in your application or in Firefox. But here it's more for your application, for
[03:24.520 --> 03:31.760]  your JavaScript or CSS stuff. This gives you insight and clues. But this is really detective
[03:31.760 --> 03:35.920]  work. When you have a bug and when you have a performance bug, that's the same. It's just
[03:35.920 --> 03:41.400]  a detective work. You have to look at the problem for different angles with different
[03:41.440 --> 03:47.800]  tools. With console.log sometimes. And this tool can make things easier. But it's just
[03:47.800 --> 03:55.520]  a tool. And yeah, that's something I think the most important with performance is that
[03:55.520 --> 04:02.520]  if you try to guess, you will guess wrong. Very commonly. Like, you know the web, right?
[04:02.520 --> 04:07.920]  You get some property on some DOM element and suddenly you get a full reflow of the
[04:07.960 --> 04:13.960]  whole page and it takes a few hundred milliseconds. And you can't see that really clearly with
[04:13.960 --> 04:20.960]  the code. So also with the JIT, with the JavaScript virtual machines, the JIT can optimize it
[04:21.560 --> 04:27.560]  for you, can optimize a lot of good things. And for other things, they will just be very
[04:27.560 --> 04:32.720]  slow and it's very difficult to know in advance. So yeah, do not guess. Try to measure being
[04:32.720 --> 04:37.320]  with the Firefox profiler, with the Chrome profiler or anything, even with performance
[04:37.360 --> 04:43.360]  that measure with timer in your code. But try to measure because not everything is always,
[04:43.360 --> 04:50.360]  it can be confused on the web, right? So now I'll try to do a live demo. Let's hopefully
[04:50.560 --> 04:57.560]  that will work. So I will show you how to capture a performance profile. Let's switch
[04:57.840 --> 05:02.480]  to that view. So this is a view of the profiler, but don't pay attention to the UI right now.
[05:02.600 --> 05:09.600]  Just because I have a bug. A bug was reported lately. This is very slow when we do a panning
[05:09.760 --> 05:16.760]  here. Like when I pan here, it's not so slow right now because the resolution is smaller
[05:17.840 --> 05:24.840]  here, but it's quite kind of slow here. So I want to measure this. I want to profile
[05:25.040 --> 05:31.880]  this. So what I'm doing is first I'm going on the profiler website. And there is this
[05:31.960 --> 05:38.240]  handy button here. Just click here. This has a profiler icon on the top with a bunch of
[05:38.240 --> 05:44.640]  settings here. So you can use, there's a settings title for web developer here. Or you can profile
[05:44.640 --> 05:50.440]  the whole navigator if you prefer, the whole browser. You can also edit settings here.
[05:50.440 --> 05:55.320]  You can change the interval, for example, if you want to reduce the overhead, or you
[05:55.320 --> 06:01.400]  can change some features. I will maybe talk about that later if I have enough time. But
[06:01.400 --> 06:08.400]  now I will just start the recording. And I will run my scenario. Like that. And then
[06:11.400 --> 06:18.400]  I can capture. And I get a view into what happened here. So we will type into the UI
[06:22.440 --> 06:26.400]  a bit later. And I will zoom in also because maybe it's a bit small for you. But I want
[06:26.440 --> 06:31.920]  to just to show you that you can also upload the profile then. Of course, there can be
[06:31.920 --> 06:36.240]  personal information in anything you can show from your browser. There can be things about
[06:36.240 --> 06:41.520]  URL you visited, about the tab that you have currently opened. Maybe there are some tabs
[06:41.520 --> 06:47.880]  you don't want anybody, everybody to know. And there can be paths in on your local computer.
[06:47.880 --> 06:54.880]  So you can disable some of these things. So for example, I will remove the, yes, the
[06:56.400 --> 07:03.400]  thread that I don't see here. I can upload here. The Wi-Fi works surprisingly well today.
[07:05.080 --> 07:10.680]  And then you have this ND URL. You can take this URL, give that to your co-worker. And
[07:10.680 --> 07:14.680]  this will open exactly the same view with the same profile. And so this is very handy
[07:14.680 --> 07:20.600]  to discuss that with your colleagues. And some of you can have different understanding
[07:20.600 --> 07:24.080]  of different types, different parts of your code. And so you can have different views
[07:24.120 --> 07:28.840]  like that. You can also share this URL with Gecko developers. If you have a problem in
[07:28.840 --> 07:34.200]  Firefox, you can open a bug, put this URL there. And that will help the Firefox developers
[07:34.200 --> 07:41.200]  solve problems that you may find in the browser. And finally, because that's your data, you
[07:41.200 --> 07:46.840]  can also delete it. There is a delete button here. You can delete the data that was uploaded.
[07:46.840 --> 07:50.240]  Because otherwise, it's public. You need to understand that it's very public. Of course,
[07:50.240 --> 07:54.120]  you need to know the URL. But otherwise, it's public. There is no password, whatever.
[07:54.120 --> 08:01.120]  So you can delete it when you don't need it anymore. So now I come back to the talk.
[08:06.400 --> 08:12.120]  We'll dive into the UI a bit later. But first, I want to explain how do you have your good
[08:12.120 --> 08:19.120]  data, yes. You need to isolate the problem as much as possible. Like, let's say you
[08:20.440 --> 08:27.440]  have a lot of tabs, lots of websites in background that are running stuff. The problem you want
[08:29.640 --> 08:36.640]  to test can be isolated. And maybe it will be some performance differences just because
[08:39.880 --> 08:45.640]  you have some websites in background. Or maybe you're building something in background
[08:45.640 --> 08:50.360]  of your computer and that will skew the results. So try to isolate the problem. Try to have
[08:50.360 --> 08:57.360]  a computer that is not too busy at that moment. When you get the data, try to ensure that
[08:58.360 --> 09:02.960]  the results you get are the ones you kind of expected. I can look at the screenshots,
[09:02.960 --> 09:07.880]  see if this is the thing you actually wanted. And you can keep recording. There is not one
[09:07.880 --> 09:14.880]  truth. There is several truths here. Depending on if your system wasn't in the best shape
[09:15.240 --> 09:19.520]  at that moment, maybe you need to record again so that you have something that you can work
[09:19.520 --> 09:26.520]  with. So no, yeah. Now I want to go into the capture data. So we have two types of data.
[09:28.360 --> 09:35.120]  The first type of data we do is sampling. So what we are doing is every interval, every
[09:35.120 --> 09:40.520]  millisecond here, we look at what the current program is executing. So we look at the stack.
[09:40.560 --> 09:45.640]  Here for example, this is an example of a program that starts with main. This is the
[09:45.640 --> 09:50.480]  main function of a program that we call A, that we call B, that we call C, C will return,
[09:50.480 --> 09:55.400]  et cetera. So this is like a normal program calling normal functions. And every millisecond
[09:55.400 --> 10:02.400]  we look at where we are. So here we are in A, no, we are in main, sorry. A, we don't see
[10:03.200 --> 10:07.640]  it here. But here we are in B. So we are in B, but we are also in A, right? And we are
[10:07.720 --> 10:14.720]  also in main. And then at this point we are also in B, in A and main. Here we are just
[10:14.720 --> 10:21.960]  in main, for example, and here we are both in main, in A, in B, and in C. And then so
[10:21.960 --> 10:28.640]  we take all these data and then we squeeze them together, which is a technical term to
[10:28.640 --> 10:35.640]  mean that we aggregate the data. So we squeeze them and so we show this information as far
[10:35.720 --> 10:41.520]  as the culture like that. So that's basically the same. So if I come back here, we can see
[10:41.520 --> 10:48.440]  basically main, we spend 100% there, right? It's the same function in the whole program.
[10:48.440 --> 10:54.160]  In A we spend maybe 70% there and in B we spend maybe 50%. And that's what we see in
[10:54.160 --> 11:01.160]  the culture then. Here the one at the top, we spend like 98% in it. But we spend also
[11:02.040 --> 11:09.040]  56 samples in, right in this function. So the difference between this column and this
[11:09.680 --> 11:16.200]  column is that this column is this function including everything it's called. And this
[11:16.200 --> 11:23.200]  column is this function only, excluding everything it called. Another view is the frame graph.
[11:23.880 --> 11:29.760]  The frame graph is the same data, it's just more visual. The time we spend in one function
[11:29.760 --> 11:36.760]  is the width of a rectangle. The one at the top are the one where we are at one point.
[11:38.360 --> 11:44.000]  So very visually we can see where we spend time. So here we can see we do a lot of converse
[11:44.000 --> 11:49.200]  rendering stuff. This is exactly the scenario I was playing earlier, by the way. So we see
[11:49.200 --> 11:53.840]  that we're spending some time on the converse and we are maybe redrawing too much stuff
[11:53.840 --> 11:58.720]  at that point. So we can dive into that later also if we have time. I don't know how much
[11:58.800 --> 12:05.800]  and we have, okay. So yes, sampling is a view into the program that is currently executing.
[12:08.000 --> 12:13.000]  But we can miss things. Like you've seen here, because we do only every millisecond we can
[12:13.000 --> 12:18.320]  miss some of the codes and maybe they're important, right? So in this case we see only once because
[12:18.320 --> 12:23.080]  it was a bit longer but the small ones here we don't see that. This can be missed. So
[12:23.080 --> 12:28.000]  that's why we can instrument the code. So Firefox itself is instrumented for important
[12:28.000 --> 12:32.800]  things like the reflows, the restyles, or the GC, or things like that. But you can also
[12:32.800 --> 12:38.800]  instrument your own code with the performance timing API, performance.mark and performance.measure.
[12:38.800 --> 12:43.680]  You will see that in the profile. So that's what we call markers in our little technical
[12:43.680 --> 12:50.680]  jargon, some other profiler called that events. And we get like another view on what's happening
[12:51.360 --> 12:56.000]  in the program here. So for example, we get, we see all the events here. This one is the
[12:56.080 --> 13:01.320]  mouse move event because that's exactly what I was doing, right? I was moving the mouse
[13:01.320 --> 13:07.160]  while I was panning. So I get mouse move events that are pretty big actually. 30 milliseconds
[13:07.160 --> 13:12.320]  for one event, that means we spend maybe too much time there. We also see all the user
[13:12.320 --> 13:18.120]  timing because the code of the profiler is instrumented to add performance.measure anytime
[13:18.120 --> 13:24.000]  we do some converse drawing. But you can also see things that's happening inside Firefox.
[13:24.000 --> 13:30.360]  We can see, for example, the restyles here, the reflow here. We can see some GC. We can
[13:30.360 --> 13:37.360]  see some, when it's awake or when it's idle. So we can see all stuff, more or less complicated.
[13:38.160 --> 13:44.920]  We want to make this view a bit simpler for web developers. Currently you have still everything.
[13:44.920 --> 13:48.680]  And you need to probably ignore a part of this and just focus on what's important for
[13:48.680 --> 13:55.680]  you, like DOM events or restyles and graphic stuff. But it gives a, like a quite, yeah,
[13:57.440 --> 14:02.440]  you get all the stuff here. So you can dive into how Firefox works. You get the animation
[14:02.440 --> 14:06.920]  stuff. I don't have animations here, but you can see CSS animation. You can see the target
[14:06.920 --> 14:13.920]  of this seven. So yeah, markers are pretty interesting. So there are limits. As I said
[14:13.920 --> 14:20.920]  earlier, you're measuring on your own computer. And this also has drawbacks. Your computer,
[14:25.120 --> 14:32.120]  as a developer, usually it's very, it's very performant, right? You have the best CPU and
[14:32.720 --> 14:37.240]  you have a sheet load of memory. And so this means that the performance on your computer
[14:37.240 --> 14:43.520]  might be different than the performance on your user's computer. And also just the act
[14:43.560 --> 14:50.560]  of profiling itself can skew the results. Because we're, by inserting markers, for example,
[14:51.440 --> 14:56.960]  we need to lock the memory in some place to insert the data there. And we need to capture
[14:56.960 --> 15:02.440]  the stack sometimes. And this takes a lot of time. And so that can skew the results.
[15:02.440 --> 15:09.440]  We try it to be constant over read, but it's not always the case. So there are limits.
[15:10.040 --> 15:14.160]  And you need to sometimes take a step back. Sometimes what you're looking at, it's not
[15:14.160 --> 15:19.040]  an absolute truth, right? It can be, yeah, it's just a tool again. It's not absolute
[15:19.040 --> 15:26.040]  truth. You can take a step back. Maybe what I'm saying is not exactly the truth. Yeah,
[15:26.520 --> 15:33.120]  that's about it. So more and more about the UI now. I will show you how we can navigate
[15:33.200 --> 15:40.200]  in this UI. So you can put that full screen. It's not this one. Yeah, full screen. And
[15:44.520 --> 15:51.520]  zooming a bit. Okay. Come back at the first one. Okay. So what we have at the top? I can't
[15:57.120 --> 16:01.000]  choose the laser because you have to use the laser that reloads everything on this computer.
[16:01.080 --> 16:05.720]  So I don't use the laser. I use my finger. So at the top here, you have what we call
[16:05.720 --> 16:10.560]  the timeline. It's a chronological view of what's happening. At the top, you can see
[16:10.560 --> 16:16.640]  the screenshots. You can even, even over them and can see what's happening. So here I was
[16:16.640 --> 16:22.000]  on the first tab and then I go to the second tab and here I'm scrolling them, scrolling
[16:22.000 --> 16:28.160]  it and panning it. And yeah, that makes it possible visually to see what's happening
[16:28.160 --> 16:33.520]  and what was your scenario. And then you have a bunch of tracks here that are interesting.
[16:33.520 --> 16:39.360]  The first one here is the parent process. This is the process that is for the UI of Firefox.
[16:39.360 --> 16:44.240]  That's not really interesting in your case. There is also the localhost here. This is
[16:44.240 --> 16:50.360]  the localhost because I was running my UI on the localhost so that I could get the name
[16:50.360 --> 16:55.840]  of the functions. They're not minified because we don't support source maps yet. That will
[16:55.920 --> 16:59.960]  happen hopefully this year. But currently, we're not supporting that. So if we want to
[16:59.960 --> 17:06.560]  see the functions I'm profiling on the development version of our application, which also has
[17:06.560 --> 17:10.000]  some implication because, of course, the development version does use the development
[17:10.000 --> 17:14.880]  version of React. And the development version of React, it's slower than the production version
[17:14.880 --> 17:20.040]  of React. So again, taking a step back is always a good idea. Knowing that, we can dive
[17:20.040 --> 17:24.920]  into what's happening. So I can dive into this part because that's where things are
[17:25.000 --> 17:31.560]  happening, right? There is nothing elsewhere. So here you have what we call the category graph
[17:31.560 --> 17:40.040]  because the colors correspond to some category. Like the blue is dumb stuff. Yellow is JavaScript
[17:40.040 --> 17:45.560]  stuff. So here we clearly see that we don't do a lot of JavaScript. We mostly do a lot of
[17:46.280 --> 17:51.480]  something else. So dumb in this case is Canvas stuff. I will switch to JavaScript actually.
[17:52.200 --> 17:59.880]  Yeah. And then we see that we are doing the field stack stuff. So we see the stack when we hover,
[17:59.880 --> 18:06.840]  right? So we see this is a full stack of React sheet stuff. And then at the end, we do a, we just
[18:06.840 --> 18:12.680]  call field racks on the convasse API. That's where we are here. And so I can hover and have
[18:13.240 --> 18:18.920]  just a sense of what's happening. Also, I'm also setting field style here, for example. And
[18:22.440 --> 18:28.040]  I can click there and just select whatever is below. So this is basically a way to navigate
[18:28.040 --> 18:34.120]  into this profile. There is a red stuff here. The red stuff means we spend more than 50 milliseconds
[18:34.120 --> 18:40.280]  on waiting on the browser to catch up. That's probably a part where we want to zoom in, by the
[18:40.280 --> 18:49.960]  way. So we can do that. I can click there. I can zoom in here. And I can look at what's below. So
[18:50.920 --> 18:56.600]  better is what you can, all details you can see. So there are a bunch of tabs.
[18:57.400 --> 19:02.040]  The first one is the code tree. I already explained you a bit of that. Then there is a
[19:02.040 --> 19:08.520]  frame graph. I can show the frame graph by clicking. It's better, right? This is something I was
[19:08.520 --> 19:15.320]  showing up earlier. So I can also hover and see what was the stack and have an idea of what's
[19:15.320 --> 19:23.080]  happening here. The stack chart is chronological way of looking at your data. So here we can see,
[19:23.080 --> 19:32.520]  for example, I think we can see that we're rendering twice, I think, for example. So we're
[19:32.520 --> 19:38.440]  doing twice the same thing. And I think we see that more here. Like for one mouse move here,
[19:39.080 --> 19:47.000]  I have two renderers here. So that's how markers are handy, right? Here it's clear. It's clear that
[19:47.000 --> 19:55.960]  for one mouse move we do two renderers. And we shouldn't do that. So I guess I fixed my problem
[19:55.960 --> 20:01.560]  here. I need to look at the code. Of course, that doesn't solve everything. But I have an
[20:01.560 --> 20:06.760]  idea of where to look at my code. It means probably that I changed some state on some
[20:06.760 --> 20:12.840]  red component and that does a new render. So we need to look at the code then and see what's
[20:12.840 --> 20:17.960]  going on. Because this is just a tool. This doesn't solve everything. But that saves a
[20:17.960 --> 20:26.600]  shitload of time to find the right data. So let's come back at the slides.
[20:27.160 --> 20:37.000]  Okay. Some more advanced topics now. We also do, so the advanced topics are
[20:38.120 --> 20:43.800]  less exposed for a reason because they're also less finished, less polished. You can enable this
[20:43.800 --> 20:49.880]  stuff from the edit settings button that I was showing earlier. And one thing you can do is
[20:49.880 --> 20:53.880]  memory allocations. So we have two types of instrumentation for that. And I think this
[20:53.880 --> 21:00.600]  is working only in Firefox nightly. One of them is you can see every allocations happening in
[21:00.600 --> 21:05.880]  Firefox. Allocations and deallocations and things that are written, that are not
[21:06.520 --> 21:11.160]  deallocated, but they should. So you can see all these and where they were allocated to.
[21:12.040 --> 21:16.920]  And so another one is the JavaScript allocation. And that works also in release, I think.
[21:17.960 --> 21:23.560]  So you can have a look at the documentation here. So one thing that could be interesting for you
[21:23.560 --> 21:29.800]  is we have an importer for Chrome and Node also. So you can take the JSON of Chrome,
[21:30.920 --> 21:35.800]  put that in the profiler from the profiler homepage, and then you can do all the things
[21:35.800 --> 21:42.600]  I was showing you earlier. You can share it. You can zoom in maybe better than in the UI of Chrome
[21:42.600 --> 21:49.560]  and use some transform that I didn't explain today. But advanced stuff you can do with the UI.
[21:49.560 --> 21:56.520]  We do that Chrome count. And that's a parenthesis. Chrome tools are also very good. And that
[21:56.520 --> 22:01.720]  provides a different angle to your application. So because it's a different browser engine.
[22:01.720 --> 22:07.160]  So on Firefox and on Chrome, maybe it makes sense that they don't work the same. So they
[22:07.160 --> 22:11.640]  won't show the same thing. That's interesting to use both tools and the one in other browsers too.
[22:13.000 --> 22:16.680]  But you can import a new tool and share with your colleagues. So that's pretty interesting.
[22:17.640 --> 22:24.600]  And you can also compare profiles. So there are some documentation in your docs. So that makes it
[22:24.600 --> 22:33.000]  possible to see the impact of a change. Like you think you fixed the problem, you can compare
[22:33.000 --> 22:38.520]  the profile before and after and maybe check that you actually fixed your problem. Because as I said
[22:38.520 --> 22:43.400]  earlier, you need to measure. Sometimes you think you fixed it and you didn't. Or maybe you fixed
[22:43.400 --> 22:48.280]  one part of it. Like you fixed one state change. But there was another one elsewhere. And so
[22:48.280 --> 22:52.920]  there is still an update happening. So my conclusion now.
[22:57.240 --> 23:03.160]  Again, the most important thing is measure and guess. I think you really remember this sentence.
[23:03.720 --> 23:09.400]  This is just a tool in your toolbox. And yeah, sometimes you need to take a step back.
[23:10.360 --> 23:16.600]  You can also use a profiler to debug. I didn't insist much on that. But because you can instrument
[23:16.600 --> 23:21.640]  your code, you can also use it to just debug your code. It's not just for performance. You can just
[23:21.640 --> 23:28.200]  get a view of what your program looks like. What's happening in your program. And finally,
[23:28.200 --> 23:32.280]  you can share profiles with your team. Especially when you're distributed like we are at Mozilla.
[23:33.240 --> 23:39.560]  You can share it, put it on metrics or ISC or whatever things you're using and go to a Zoom
[23:39.560 --> 23:50.120]  code and then talk about that together. And thank you for being here at that time of the Sunday.
[23:50.440 --> 24:01.960]  So you can find the Firefox Profiler website here. Documentation also here. We have a
[24:01.960 --> 24:07.720]  matrix channel. So come tell if you have questions. If you have a question about a profile you want to
[24:07.720 --> 24:13.720]  ask or help to analyze it, come here. Ask us. We will gladly help you. And this slide you can
[24:13.720 --> 24:18.520]  find them here with this QR code too. So happy to answer questions now if you have questions.
[24:18.520 --> 24:22.200]  Thank you. So the microphone is here. There is a question there.
[24:26.040 --> 24:30.840]  I am very curious how you ensure security of the profile information because if I am
[24:31.800 --> 24:36.760]  on my usual admin account and I'm debugging and all the network information is there,
[24:36.760 --> 24:42.200]  it will have all the tokens and everything. All the API responses probably have the API keys
[24:42.200 --> 24:48.440]  because I'm debugging stuff. And somebody nefarious with a strong Russian accent could be
[24:49.320 --> 24:55.000]  waiting and just iterating over all the possible URLs all the time. And how do you deal with that?
[24:56.200 --> 25:04.680]  So let me refer to the question. What about the security? Because you can have API keys
[25:05.480 --> 25:12.840]  in the capture data, right, for example. So yes, that happens. But when you share a profile,
[25:12.840 --> 25:18.680]  you can uncheck the thing, include URLs and that will remove everything related to URLs. So
[25:19.480 --> 25:24.040]  you won't have that anymore. We don't capture headers and all that currently. We just capture
[25:24.040 --> 25:31.800]  the URLs. Even in the network configuration? Yeah. Okay. So it's not like the normal.
[25:34.680 --> 25:42.360]  Thanks for the talk. Small question. I believe there is kind of the same tool in the performance
[25:42.360 --> 25:49.480]  tab of the Firefox developer edition DevTools. Is there any difference between the two programs?
[25:49.480 --> 25:55.240]  Good question. I wanted to mention that I forgot. There used to be a performance panel in DevTools.
[25:55.880 --> 26:01.880]  We removed it. Now it's been replaced by this one. But we still have a performance panel in
[26:02.360 --> 26:08.200]  the DevTools. It's the same thing, except that when you open your DevTools, you have some overhead.
[26:09.080 --> 26:13.880]  So our recommendation is that you use the pop-up like I've shown here.
[26:15.000 --> 26:19.000]  Okay. So general recommendation, use the external profile. Okay.
[26:20.440 --> 26:26.360]  You can also profile your Firefox Android and you can profile remotely like that using the DevTools.
[26:27.000 --> 26:32.520]  Smaller question. Are there plans to add support for like flame graphs generated from
[26:33.400 --> 26:37.800]  birth, for example, for native applications just to use it as a kind of a viewer for
[26:38.360 --> 26:43.080]  other births not related to the web? Yes. So we have an importer for Linux birth,
[26:43.080 --> 26:48.600]  actually. We have some documentation about that. There is also the fantastic tool by Markus,
[26:48.680 --> 26:55.720]  which is somewhere here called Sempli. That is very well integrated with the profiler to
[26:56.920 --> 27:05.160]  profile native applications to. So it's called Sempli, S-A-M-P-L-Y. You can compile it on your
[27:05.160 --> 27:13.640]  computer. It's made in Rust and this is just an amazing tool to profile your native applications.
[27:13.640 --> 27:20.520]  So you can try that. Hello. It is the way to profile a full stack application.
[27:21.560 --> 27:25.960]  I mean the front end and the back end in the same time.
[27:29.800 --> 27:39.320]  You can't do that in the same time currently. What you can do is you can profile with of
[27:39.320 --> 27:46.600]  course the full stack. So it's probably not in back end maybe. Not Python. So there is a
[27:46.600 --> 27:52.440]  tool called FunctionTrade that I don't know well. That is using the profiler to profile
[27:52.440 --> 27:57.400]  Python applications. I don't know much about that. So I don't want to say too much things about that.
[27:58.280 --> 28:06.840]  So currently we can't do what you're saying directly. So sorry. Last question and then we'll
[28:06.840 --> 28:13.000]  close the room after of course all of us pick up all the trash that would be left if any.
[28:14.840 --> 28:21.000]  Thank you for the talk. Is there any plans to add support for importing P-Profiles which like
[28:21.000 --> 28:29.320]  some profilers output? So can you repeat that again? Sorry. Are there any plans to add support
[28:29.320 --> 28:34.600]  for P-Profiles which like for instance Go produces as an output of the profiler?
[28:37.480 --> 28:44.200]  You mean to have output of no I think I didn't get the question. Sorry. The output like the
[28:44.200 --> 28:51.880]  P-Profile format which is for profiling like we can get P-Profs with this viewer. Okay. We don't
[28:51.880 --> 28:59.480]  have we don't have really a plan but it's easy to I mean easy. It's not really easy but it's
[28:59.480 --> 29:04.760]  possible to write converters for our format. Our format is very well documented. So we have
[29:04.760 --> 29:15.400]  converter for Linux perf for Valgrants format called DHAT I think for ArcTrace for Chrome.
[29:16.200 --> 29:24.120]  And currently that's all but we also have an external converter for ETW from Windows and for
[29:24.120 --> 29:31.880]  I think GPR for GVM stuff. So it's possible to do converters. No we just need somebody to do it.
[29:32.840 --> 29:39.240]  Sorry. But if there is enough interest now maybe you can look at looking to it or at least help
[29:39.240 --> 29:46.200]  somebody doing do it. Thanks again and I don't know if you're going to be hanging around outside
[29:46.200 --> 29:52.520]  if you want to chat. And there are more stickers. And there were stickers. Thank you.