Browser Source Organization - Include Files
Ben Goodger
- Having many files is easier for code maintainability and reuse
An idea for one component-per-file browser source organization happiness
(simplified to get the point across):
browser.xul:
#ifdef DEBUG
<script type="application/x-javascript"
src="chrome://browser/content/component1.js"/>
<script type="application/x-javascript"
src="chrome://browser/content/component2.js"/>
#endif
browser.js
#ifndef DEBUG
#include component1.js
#include component2.js
#endif
This means the error line numbers should be fairly predictable for debug
builds (well, easier to compute at least than browser.js is now... the
file is so long and there are so many #ifdefs that the printed number
has no relation at all to reality).
I'm trying an experiment like this now with the charset menu.
-Ben
Axel Hecht
How does that impact extension development?
As I don't understand fastload cache, should it be able to take that
off? I wonder how much of a perf hit multiple script nodes really are.
It seems like the xul content sink at least tries to load scripts from
fastload first. Not sure how a completely fastloaded xul doc handles this.
Axel
Ben Goodger
> How does that impact extension development?
Shouldn't change anything... script still loaded into same scope.
> As I don't understand fastload cache, should it be able to take that
> off? I wonder how much of a perf hit multiple script nodes really are.
> It seems like the xul content sink at least tries to load scripts from
> fastload first. Not sure how a completely fastloaded xul doc handles this.
This may be true, but not sure how this scales over N script files. I
know there was a non-zero improvement when all the individual files were
collapsed initially.
-Ben
Myk Melez
> - Loading fewer files at startup in optimized builds is better
> - Having many files is easier for code maintainability and reuse
>
> An idea for one component-per-file browser source organization happiness
Seems reasonable, although it makes chrome errors in optimized builds
more difficult to trace (but presumably this capability is less
important than maximizing startup time on those builds).
A related problem is that licenses appear in many JS files as
preprocessor directives. When those get stripped out (even in debug
builds), it skews the line numbers by ~50 lines (depending on the number
of contributors).
-myk
Axel Hecht
> Ben Goodger wrote:
>> - Loading fewer files at startup in optimized builds is better
>> - Having many files is easier for code maintainability and reuse
>>
>> An idea for one component-per-file browser source organization happiness
> > ...
>
> Seems reasonable, although it makes chrome errors in optimized builds
> more difficult to trace (but presumably this capability is less
> important than maximizing startup time on those builds).
This aspect is the part that triggered my extension development
question. Once we mangle different files into one, it's hard to find the
code in lxr or the source to find out what one (extension author) is
doing wrong, or even worse, where one should upstream a bug-fix
discovered by the extension.
> A related problem is that licenses appear in many JS files as
> preprocessor directives. When those get stripped out (even in debug
> builds), it skews the line numbers by ~50 lines (depending on the number
> of contributors).
Shouldn't the preprocessor spew out #line directives in js to fix that?
I thought so.
Axel
Myk Melez
> Myk Melez wrote:
>> A related problem is that licenses appear in many JS files as
>> preprocessor directives. When those get stripped out (even in debug
>> builds), it skews the line numbers by ~50 lines (depending on the
>> number of contributors).
>
> Shouldn't the preprocessor spew out #line directives in js to fix that?
Indeed it does now do that (last time I checked, it didn't, but I guess
it's been added since then). Perhaps we could adapt this solution to
the component-per-file line number problem by having the preprocessor
also add "file" directives to the combined file in optimized builds.
-myk