Re: XPIDL trajectory
On Wed, Jun 27, 2018 at 01:24:27PM +1000, Nicholas Nethercote wrote: > Thanks for the tip. I've updated the last part of the script accordingly: > > # Count number of bytes in the xptdata.o file. > cd o64 > echo -n "xptdata.o bytes: " > wc --bytes xpcom/reflect/xptinfo/xptdata.o > cd .. > > The current measurements are now: > > Tue, Jun 26, 2018: m-i 423583:4a20ed6e2fee > .idl files: 905 > .idl lines: 97278 total > xptdata.o bytes: 1139160 That includes debug info, though. You may want to look at the output of `size xptdata.o`, and take the decimal sum in the fourth column. Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: XPIDL trajectory
Thanks for the tip. I've updated the last part of the script accordingly: # Count number of bytes in the xptdata.o file. cd o64 echo -n "xptdata.o bytes: " wc --bytes xpcom/reflect/xptinfo/xptdata.o cd .. The current measurements are now: Tue, Jun 26, 2018: m-i 423583:4a20ed6e2fee .idl files: 905 .idl lines: 97278 total xptdata.o bytes: 1139160 Nick On Tue, Jun 26, 2018 at 8:50 PM, Nika Layzell wrote: > Measuring the size of the xpt files is no longer as relevant. Since mccr8 > and I rewrote xptinfo, they're only used during the build step, and are not > bundled. They're combined into a single .cpp file (xptdata.cpp) which > generates shared static pages (mostly) without relocations :-). > > Perhaps measuring the size of xptdata.o could be more useful? > > - Nika > > On Tue, Jun 26, 2018, 12:31 AM Nicholas Nethercote > wrote: > >> Hi, >> >> After Firefox 57 removed support for legacy extensions, I decided to >> (roughly) track how much XPIDL code we have. Here are some measurements: >> >> Fri, Aug 4, 2017: m-i 372493:72873c109b1b >> .idl files: 1167 >> .idl lines: 110240 total >> .xpt bytes: 417621 total >> >> Thu, Aug 17, 2017: m-i 375206:7a794cd2aee1 >> .idl files: 1150 >> .idl lines: 108854 total >> .xpt bytes: 412984 total >> >> Tue, Sep 26, 2017: m-i 382849:42a6a1c9c4cf >> .idl files: 1122 >> .idl lines: 107963 total >> .xpt bytes: 411283 total >> >> Tue, Nov 14, 2017: m-i 391533:479f3105ad3b >> .idl files: 1087 >> .idl lines: 106809 total >> .xpt bytes: 409510 total >> >> Thu, Feb 01, 2018: m-i 401956:8ebdf597ade8 >> .idl files: 1027 >> .idl lines: 103800 total >> .xpt bytes: 398695 total >> >> Tue, Jun 26, 2018: m-i 423583:4a20ed6e2fee >> .idl files: 905 >> .idl lines: 97278 total >> .xpt bytes: 3717958 total >> >> The trend is clearly down, except for the large increase in .xpt size for >> the most recent measurement -- note the extra digit! It appears that .xpt >> files used to be binary, and now they are JSON. This might be related to >> mccr8's recent XPT overhaul (bug 1438688)? >> >> The script I use for this is below, for those who are interested. >> >> Nick >> >> >> #! /bin/sh >> # >> # Measures various XPIDL things in ./ and o64/. (It assumes o64/ is the >> # objdir.) I put the results in ~/moz/txt/xpidl.txt. >> >> if [ ! -d o64 ] ; then >> echo "o64/ doesn't exist" >> return 1 >> fi >> >> # Count number of .idl files, excluding ones in objdirs, testing ones, and >> # mortar ones. >> echo -n ".idl files: " >> find . -name '*.idl' | \ >> grep -v "64[a-z]*\/dist" | grep -v "testing\/" | grep -v "mortar\/" | >> \ >> wc --lines >> >> # Count number of lines in those .idl files. >> echo -n ".idl lines: " >> find . -name '*.idl' | \ >> grep -v "64[a-z]*\/dist" | grep -v "testing\/" | grep -v "mortar\/" | >> \ >> xargs wc --lines | tail -1 >> >> # Count number of bytes in .xpt files. >> cd o64 >> echo -n ".xpt bytes: " >> find . -name '*.xpt' | xargs wc --bytes | tail -1 >> cd .. >> ___ >> dev-platform mailing list >> dev-platform@lists.mozilla.org >> https://lists.mozilla.org/listinfo/dev-platform >> > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: XPIDL trajectory
Measuring the size of the xpt files is no longer as relevant. Since mccr8 and I rewrote xptinfo, they're only used during the build step, and are not bundled. They're combined into a single .cpp file (xptdata.cpp) which generates shared static pages (mostly) without relocations :-). Perhaps measuring the size of xptdata.o could be more useful? - Nika On Tue, Jun 26, 2018, 12:31 AM Nicholas Nethercote wrote: > Hi, > > After Firefox 57 removed support for legacy extensions, I decided to > (roughly) track how much XPIDL code we have. Here are some measurements: > > Fri, Aug 4, 2017: m-i 372493:72873c109b1b > .idl files: 1167 > .idl lines: 110240 total > .xpt bytes: 417621 total > > Thu, Aug 17, 2017: m-i 375206:7a794cd2aee1 > .idl files: 1150 > .idl lines: 108854 total > .xpt bytes: 412984 total > > Tue, Sep 26, 2017: m-i 382849:42a6a1c9c4cf > .idl files: 1122 > .idl lines: 107963 total > .xpt bytes: 411283 total > > Tue, Nov 14, 2017: m-i 391533:479f3105ad3b > .idl files: 1087 > .idl lines: 106809 total > .xpt bytes: 409510 total > > Thu, Feb 01, 2018: m-i 401956:8ebdf597ade8 > .idl files: 1027 > .idl lines: 103800 total > .xpt bytes: 398695 total > > Tue, Jun 26, 2018: m-i 423583:4a20ed6e2fee > .idl files: 905 > .idl lines: 97278 total > .xpt bytes: 3717958 total > > The trend is clearly down, except for the large increase in .xpt size for > the most recent measurement -- note the extra digit! It appears that .xpt > files used to be binary, and now they are JSON. This might be related to > mccr8's recent XPT overhaul (bug 1438688)? > > The script I use for this is below, for those who are interested. > > Nick > > > #! /bin/sh > # > # Measures various XPIDL things in ./ and o64/. (It assumes o64/ is the > # objdir.) I put the results in ~/moz/txt/xpidl.txt. > > if [ ! -d o64 ] ; then > echo "o64/ doesn't exist" > return 1 > fi > > # Count number of .idl files, excluding ones in objdirs, testing ones, and > # mortar ones. > echo -n ".idl files: " > find . -name '*.idl' | \ > grep -v "64[a-z]*\/dist" | grep -v "testing\/" | grep -v "mortar\/" | \ > wc --lines > > # Count number of lines in those .idl files. > echo -n ".idl lines: " > find . -name '*.idl' | \ > grep -v "64[a-z]*\/dist" | grep -v "testing\/" | grep -v "mortar\/" | \ > xargs wc --lines | tail -1 > > # Count number of bytes in .xpt files. > cd o64 > echo -n ".xpt bytes: " > find . -name '*.xpt' | xargs wc --bytes | tail -1 > cd .. > ___ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: XPIDL trajectory
On 6/26/18 12:45 AM, L. David Baron wrote: What's the relative value of making something not use xpidl anymore vs. marking an xpidl interface as no longer [scriptable]? I think the main value is in not using xpidl anymore, for two reasons: 1) You can't devirtualize things while still using xpidl. Removing xpidl bits means your objects might get smaller (fewer vtable pointers), our relocatable data gets smaller (fewer vtables), and runtime likely gets faster. 2) It's hard to get sane C++ method signatures while using xpidl. You _can_ do it with [notxpcom,nostdcall] and enought native-type declaration. But it requires some hoop-jumping. And at that point what's the benefit of using xpidl for it? -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: XPIDL trajectory
On Mon, Jun 25, 2018 at 09:45:22PM -0700, L. David Baron wrote: On Tuesday 2018-06-26 14:29 +1000, Nicholas Nethercote wrote: The trend is clearly down, except for the large increase in .xpt size for the most recent measurement -- note the extra digit! It appears that .xpt files used to be binary, and now they are JSON. This might be related to mccr8's recent XPT overhaul (bug 1438688)? What's the relative value of making something not use xpidl anymore vs. marking an xpidl interface as no longer [scriptable]? (I hope that marking it not [scriptable] would mean we don't generate .xpt data for it... although I haven't checked. I *think* mccr8's XPT work means that we no longer have duplicate in-memory copies of the xpt data across processes, though, so some of this isn't as big a deal as it used to be.) For C++, it generally means fewer vtables/virtual calls (which is currently a significant win for content process memory), and generally a nicer API surface. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: XPIDL trajectory
On Tuesday 2018-06-26 14:29 +1000, Nicholas Nethercote wrote: > The trend is clearly down, except for the large increase in .xpt size for > the most recent measurement -- note the extra digit! It appears that .xpt > files used to be binary, and now they are JSON. This might be related to > mccr8's recent XPT overhaul (bug 1438688)? What's the relative value of making something not use xpidl anymore vs. marking an xpidl interface as no longer [scriptable]? (I hope that marking it not [scriptable] would mean we don't generate .xpt data for it... although I haven't checked. I *think* mccr8's XPT work means that we no longer have duplicate in-memory copies of the xpt data across processes, though, so some of this isn't as big a deal as it used to be.) -David -- 턞 L. David Baron http://dbaron.org/ 턂 턢 Mozilla https://www.mozilla.org/ 턂 Before I built a wall I'd ask to know What I was walling in or walling out, And to whom I was like to give offense. - Robert Frost, Mending Wall (1914) signature.asc Description: PGP signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
XPIDL trajectory
Hi, After Firefox 57 removed support for legacy extensions, I decided to (roughly) track how much XPIDL code we have. Here are some measurements: Fri, Aug 4, 2017: m-i 372493:72873c109b1b .idl files: 1167 .idl lines: 110240 total .xpt bytes: 417621 total Thu, Aug 17, 2017: m-i 375206:7a794cd2aee1 .idl files: 1150 .idl lines: 108854 total .xpt bytes: 412984 total Tue, Sep 26, 2017: m-i 382849:42a6a1c9c4cf .idl files: 1122 .idl lines: 107963 total .xpt bytes: 411283 total Tue, Nov 14, 2017: m-i 391533:479f3105ad3b .idl files: 1087 .idl lines: 106809 total .xpt bytes: 409510 total Thu, Feb 01, 2018: m-i 401956:8ebdf597ade8 .idl files: 1027 .idl lines: 103800 total .xpt bytes: 398695 total Tue, Jun 26, 2018: m-i 423583:4a20ed6e2fee .idl files: 905 .idl lines: 97278 total .xpt bytes: 3717958 total The trend is clearly down, except for the large increase in .xpt size for the most recent measurement -- note the extra digit! It appears that .xpt files used to be binary, and now they are JSON. This might be related to mccr8's recent XPT overhaul (bug 1438688)? The script I use for this is below, for those who are interested. Nick #! /bin/sh # # Measures various XPIDL things in ./ and o64/. (It assumes o64/ is the # objdir.) I put the results in ~/moz/txt/xpidl.txt. if [ ! -d o64 ] ; then echo "o64/ doesn't exist" return 1 fi # Count number of .idl files, excluding ones in objdirs, testing ones, and # mortar ones. echo -n ".idl files: " find . -name '*.idl' | \ grep -v "64[a-z]*\/dist" | grep -v "testing\/" | grep -v "mortar\/" | \ wc --lines # Count number of lines in those .idl files. echo -n ".idl lines: " find . -name '*.idl' | \ grep -v "64[a-z]*\/dist" | grep -v "testing\/" | grep -v "mortar\/" | \ xargs wc --lines | tail -1 # Count number of bytes in .xpt files. cd o64 echo -n ".xpt bytes: " find . -name '*.xpt' | xargs wc --bytes | tail -1 cd .. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
