Ruby's Louvre

每天学习一点点算法

导航

< 2025年3月 >
23 24 25 26 27 28 1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31 1 2 3 4 5

统计

mass.query v3 发布

我想query v2这种设计思路已到瓶颈了,把选择器群组切割成最小颗粒,然后在循环中从文档对象找到一个或多个节点,然后再到下一个循环找到它们的孩子或直接从它们当中筛选……为此付出的代价也非常多——颗粒越多,循环次数也越多,虽然我在每个分支不断让指针向后移。但这也太累了,有些颗粒需要合并了才有意义。不过最令人痛心的问题是,也是所有从左到右选择的选择器不得不面临问题是,如果出现并联、亲子、兄长、相邻等选择器,得到的元素集合就很有可能不是按文档顺序排列。因此我下一版将尝试从右到左。不过从右到左最大的问题就是后代选择器,这种不断往上回溯的算法非常难,这也是jQuery在处理关系选择器容易出现错的原因。

其实无论是从左到右,还是从右到左,只要能把代码量压缩我都无怨言。因为很快就步入IE9的时代,querySelectorAll将支持更多的伪类(而且更有用)。因此这样人为的选择器只为向前兼容而存在,这样的代码我当然希望它占用我框架代码量的比重越少越好。我最近也想到几种方法,能让我的选择器跑得更快,但这也增加200多行代码,于是我不干了。

有人提出20/80原则,但这意味着一些选择器跑不了,但我宁愿慢一点也不愿放弃支持。其实选择一个或多个元素速度根本可以忽略不计,性能都耗在处理节点的各种操作上。

有人抱怨大循环的分支非常复杂,但明显易读性与执行效率往往不是一伙的,就像排序算法,越快的实现就越难看懂。这次把结构做好的,相对的,速度被拉下来了。

我知道,需要新的思路了……

如果您觉得此文有帮助,可以打赏点钱给我支付宝1669866773@qq.com ,或扫描二维码

posted on   司徒正美  阅读(2780)  评论(9编辑  收藏  举报

编辑推荐:
· Linux系列:如何用 C#调用 C方法造成内存泄露
· AI与.NET技术实操系列(二):开始使用ML.NET
· 记一次.NET内存居高不下排查解决与启示
· 探究高空视频全景AR技术的实现原理
· 理解Rust引用及其生命周期标识(上)
阅读排行:
· 物流快递公司核心技术能力-地址解析分单基础技术分享
· .NET 10首个预览版发布:重大改进与新特性概览!
· 单线程的Redis速度为什么快?
· 展开说说关于C#中ORM框架的用法!
· Pantheons:用 TypeScript 打造主流大模型对话的一站式集成库
点击右上角即可分享
微信分享提示