V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  Claar  ›  全部回复第 2 页 / 共 4 页
回复总数  75
1  2  3  4  
2021-02-14 18:49:04 +08:00
回复了 Claar 创建的主题 问与答 良心云的海外节点是否可以用于 google 搜索?
@baiduyixia 难受,想换个稳定点的去油管看 vr,不是服务器的话好像流量都压的很低……不知道有啥好用的
2021-02-10 19:42:52 +08:00
回复了 szzhiyang 创建的主题 程序员 建议不常用右 Shift 键的 V 友学习正确的打字指法
建议先打字比我快,不然我乱打都比你"正确"的打要快的话,会很尴尬
2021-02-08 19:30:33 +08:00
回复了 crazychang 创建的主题 问与答 今年本科毕业 只会装系统 刷机 ,不知何去何从
@66beta 50 睡醒了没啊
福建这种弱省的水一本都不到 20
广东大概就 10 多点
哪个省 50 啊?那还用高考复习?读完高二直接去干都闭眼上
2021-02-08 17:49:37 +08:00
回复了 Steps 创建的主题 职场话题 大家还在公司的,你们的公司气氛是什么样子的?
摸鱼
2021-02-08 17:48:52 +08:00
回复了 aspriny 创建的主题 职场话题 让我来看看今天还有谁在上班
明天 9 号还要上到下午
2021-02-08 15:42:29 +08:00
回复了 Peakday 创建的主题 Go 编程语言 查找匹配文本这段代码运行起来很慢是什么原因
@YouLMAO #9 包裹给 150 是什么意思啊,不过我曾经花过大概 3 小时不到根据知乎上描述的正则表达式原理实现过正则,花了一小时不到学习实现了 trie 然后花了一小时不到学习优化成了 AC 自动机,感觉 AC 自动机不难。我半年不刷题直接写应该一小时也够了
2021-02-08 14:48:54 +08:00
回复了 Peakday 创建的主题 Go 编程语言 查找匹配文本这段代码运行起来很慢是什么原因
@Claar 前面表述错了,AC 自动机和 trie 都是多模式匹配,AC 自动机的优势在于 trie 失败后直接转向下一个可能的 pattern,属于不定型的模式匹配优化,但是在这个例子中一个字串必然属于一个反前缀顺序的确定模式,直接 trie 就对了
2021-02-08 14:37:21 +08:00
回复了 monkeyWie 创建的主题 Go 编程语言 求 go 并发限制的最佳实现
并发控制:协程池
消息传递:channel
还有等待协程结束再结束 main 函数:sync.
甚至可以子任务报错直接 exit
2021-02-08 14:29:15 +08:00
回复了 Peakday 创建的主题 Go 编程语言 查找匹配文本这段代码运行起来很慢是什么原因
@guonaihong 就用题主说到的
a.com b.com c.com
ba.a.com fg.b.com
格式可好?
2021-02-08 14:25:54 +08:00
回复了 Peakday 创建的主题 Go 编程语言 查找匹配文本这段代码运行起来很慢是什么原因
@guonaihong 我也没有数据啊,不过我对你的实现倒是有点感兴趣,请问可否放出来看看?
2021-02-08 10:49:04 +08:00
回复了 Peakday 创建的主题 Go 编程语言 查找匹配文本这段代码运行起来很慢是什么原因
@guonaihong 我的理解你这变成了不定长匹配,会更慢
2021-02-08 01:54:17 +08:00
回复了 Peakday 创建的主题 Go 编程语言 查找匹配文本这段代码运行起来很慢是什么原因
@Peakday #5 感觉 4s 还是有点慢?
2021-02-08 01:48:08 +08:00
回复了 Peakday 创建的主题 Go 编程语言 查找匹配文本这段代码运行起来很慢是什么原因
@heart4lor #6 我记得 AC 自动机应该是适用于类似正则的多模式匹配吧,他比 trie 的优化和单模式匹配的 KMP 之于暴力搜索一样,通过前缀这个特征去省略掉不必要的搜索
这里应该是直接使用反的前缀比较快,毕竟这里的域名是已知的
2021-02-07 22:01:42 +08:00
回复了 Peakday 创建的主题 Go 编程语言 查找匹配文本这段代码运行起来很慢是什么原因
我的我没注意到子域名的问题,这种情况还是直接反前缀匹配吧
2021-02-07 21:56:26 +08:00
回复了 Peakday 创建的主题 Go 编程语言 查找匹配文本这段代码运行起来很慢是什么原因
我认为反前缀的思路感觉也可以,就是应该比正常写法稍慢

我放到 IDE 里认真看才意识到这个写法真的是巨憨批
直接正则匹配所有的 domain,再遍历分析数量不可以吗?

我认为你的问题是你正则了 1200 次全文,这简直顶级憨批行为
2021-02-07 11:54:07 +08:00
回复了 wapzjn 创建的主题 问与答 想换个城市,能否给个推荐
暖且互联网不就是深圳吗?广州感觉互联网气息不够钱
感觉常见的回收 app 都不如闲鱼
2021-02-07 00:44:09 +08:00
回复了 zoeliu 创建的主题 问与答 请教 同一网络环境,通过 ip:port 的方式访问本地部署的网站
@zoeliu grep 整个文件夹搜索一下关键字?
2021-02-07 00:42:09 +08:00
回复了 jianzong 创建的主题 推广 [送码] 猜对腾讯股价,赠送 Percento iOS 高级会员
722
2021-02-01 15:51:35 +08:00
回复了 fxybk 创建的主题 问与答 一道数据结构相关的题,请教一下站里的大神们
@fxybk #10
哈哈哈其实简单的判断并不难,只需要知道
1.哈希表是多数情况下 key-value 储存算法的选择,他的算法复杂度不高,效率相对来说应该是能经过考验的。另外“hash”也是指具体的“实现方式”
2.树形是常见普通人手写 key-value 算法选择,和哈希表对比可能他的速度稍稍差一点点(但是树形实现多数情况下速度也很优秀了,如果选用具体的如红黑树这种经典树形实现(红黑树算是树里面相当优秀的),基本是很够用了),且树形相对哈希来说可能好写一些(这只是个人认为)
3.像哈希这种优秀的算法比较大的缺点是空间占用不小,一般来说你要储存 100 个 key-value 可能需要 300 个左右的空间
4.相对来说树的具体实现,红黑树是很优秀的,但难写一些,AVL 没红黑树强,但依然优秀,且比较好写
5.树形实现速度也很快,复杂度是 O(log N),大概就是总量为 2 ^ 20 次方的数据,每次查找差不多只需要查 20 个数据即可,而和一般的如队列从头找到尾的查找方案对比是快的没边了
6.LRU 是缓存置换算法,并不是具体的“实现”,只是一种思想形成的结构,也就是说只要满足一定的特征就能称为 LRU,但是具体实现方案的不同,效率可能差很远

在没有特殊技巧的前提下,如果侧重速度,选用哈希表 /树来储存 key-value 应该平均下来最快的了。
如果有特殊技巧,比如:最近用过的数据接下来被使用的几率更高这种规律下,如果频繁的进行查找最近用过的几个数据,那么队列的实现会快一丢丢(因为虽然有 2 ^ 20 个数据,但你查来查去只查前面几个,那当然容易啊)
而且“最近用过的数据接下来被使用的几率更高”这种规律其实只是像算力“摩尔定律”一样只是人为粗略的概括起来的一种规律,实际效果比较玄学,如果不是空间很有限的话,我认为根本没必要使用严格的 LRU 实现,直接使用自带的哈希表存下来就可以了;而使用如(链表+哈希表)来实现的 LRU 其实就是用链表来占据“最近用过的数据接下来被使用的几率更高”的优势,除了用哈希表来查找之外,链表可以加速排在前面的项的查找,并且方便把久远没用的数据丢掉来减小空间占用


综上:如果想要实现简单,直接用语言自带的哈希表走起,不过这太简单了,估计不是人家想考的,如果要实现 LRU 的话,最好是用链表+哈希表,用哈希表来找具体位置,关于规律的部分就是把最新用的数据排到最前面,每次查找完就把这个数据放到最前排就可以了
1  2  3  4  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2655 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 26ms · UTC 09:35 · PVG 17:35 · LAX 01:35 · JFK 04:35
Developed with CodeLauncher
♥ Do have faith in what you're doing.