应该说这个问题是gfwlist过于臃肿加上全部使用正则导致的。
foxyproxy本身还是可以用的，虽然我也一直觉得它性能不怎么样，特别是以前订阅gfwlist时。所以后来我放弃了gfwlist，开始维护自用的url patterns，无任何正则，全部使用通配符，有遇到要代理的新网址就使用quickadd（alt+F2快捷键被我改成了alt+2）。使用上感觉流畅了不少。

alanfly：4M够了吧，gfwlist里6000多条规则才110KB，4M该有20多万条规则了。回到原帖

要算对象展开后的占用。

myhead：应该说这个问题是gfwlist过于臃肿加上全部使用正则导致的。
foxyproxy本身还是可以用的，虽然我也一直觉得它性能不怎么样，特别是以前订阅gfwlist时。所以后来我放弃了gfwlist，开始维护自用的url patterns，无任...回到原帖

并不是gfwlist臃肿，要按Adblock Plus的引擎解析、优化，规则大多不是正则，而是哈希表。

yfdyh000：要算对象展开后的占用。回到原帖

原来如此。  
没考虑到中国用户还有x墙的需求。

@alanfly

4m 是用于 PAC 解析的 javascript 运行时的堆大小
不是指 PAC 原始文件大小
根据 bug 1250776 的描述
在这个问题修复之前
112.41 KB 的 pac 可以工作
而 112.46 KB 就不行了
同时，这个 pac 就是来自 shadowsocks 的 gfwlist2pac

另外
看 chrome 那个 bug 的 coment 5
友邦人士从一个 6.64MB 的原始列表生成了一个 2.41MB 的 PAC

aaaa007cn：@alanfly

4m 是用于 PAC 解析的 javascript 运行时的堆大小
不是指 PAC 原始文件大小
根据 bug 1250776 的描述
在这个问题修复之前
112.41 KB 的 pac 可以工作
而 112.46 KB...回到原帖

怪不得gfwlist刚好110KB。  
那个pac现在是3.4MB了，下下来看不懂，pac格式开头，内容不是常见的列表式的，不知道是什么东西这么大。

alanfly：怪不得gfwlist刚好110KB。  
那个pac现在是3.4MB了，下下来看不懂，pac格式开头，内容不是常见的列表式的，不知道是什么东西这么大。回到原帖

那个 bug 是一月三号发的
这半年不到就 3MB+ 了啊
看了下
它是直接匹配 ip、域名的
把 ip、域名按 . 分割
然后分别从前往后、从后往前依次 switch case 判断
不知道为什么会这么做就是了

问下autoproxy能指定本地的pac吗？

jaleo：问下autoproxy能指定本地的pac吗？回到原帖

不能，火狐本身就支持加载pac

这几个到 WebExtension 就得挂了。。。哎。。。现在一直在寻找比较好的方案过度。。。

那Pan和Autoproxy-ng相比的话性能如何呢？

chrome商店 中一个 pp vpn，有移植吗？

q11：chrome商店 中一个 pp vpn，有移植吗？回到原帖

没有 装chrome store foxified 扩展以后到chrome 商店强行安装试试。不过vpn现在封的厉害