search

cicku / libproxy

Automatically exported from code.google.com/p/libproxy
GNU Lesser General Public License v2.1
1 stars 0 forks source link

Always make pacrunner as module (never should be build-in) #137

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago 
Currently in libproxy/cmake/modules.cmk it is defined that if there's only one 
JS-engine found, it will be built into libproxy, rather than as a module. It is 
wasting memory to load a big JS-engine into memory along with libproxy if the 
user is not using PAC at all, therefore I think it's better to build pacrunner 
always as module no matter how many of them are found.

Original issue reported on code.google.com by elliot...@gmail.com on 25 Aug 2010 at 8:38

GoogleCodeExporter commented 8 years ago

Original comment by nicolas.dufresne@gmail.com on 31 Aug 2010 at 7:44

GoogleCodeExporter commented 8 years ago 
Note, some measurement would be a nice to have, but I don't pretend your 
assumption is wrong.

Original comment by nicolas.dufresne@gmail.com on 31 Aug 2010 at 8:29

GoogleCodeExporter commented 8 years ago 
After re-reading the code, I see that PAC runners are loaded when the 
ProxyFactory is created, which mean the JavaScript engine library is also 
loaded whenever you have a PAC file configured or not. In this case the memory 
gain is 0.

Original comment by nicolas.dufresne@gmail.com on 1 Sep 2010 at 8:01

GoogleCodeExporter commented 8 years ago 
But if I don't need to use PAC file, I can just remove the PAC runner module, 
and this can reduce both memory and storage footprint.

The problem you mentioned (that PAC runner will always be loaded) worthy 
reporting another bug I think.

Original comment by elliot...@gmail.com on 6 Sep 2010 at 11:54

GoogleCodeExporter commented 8 years ago 
No don't, packagers will build them all and put them in seperate packages, so 
it's not an issue.

Original comment by nicolas.dufresne@gmail.com on 7 Sep 2010 at 12:03