kozmosovia 发表于 2024-4-15 09:13
画什么图需要用到天天合并8W的线条？就为了偶尔省一下30s，意义不大。
这个是真实的工作案例，2700条线，测试两次，一次8秒，一次17秒。
kozmosovia 发表于 2024-4-15 09:13
画什么图需要用到天天合并8W的线条？就为了偶尔省一下30s，意义不大。
倒也不是为了省30秒，而是为了防止卡死崩溃。
aws 发表于 2024-4-15 09:36
倒也不是为了省30秒，而是为了防止卡死崩溃。
卡死就卡死吧,ssget还容易漏,还是不要考虑什么分区了吧...
如果要分区用ssget你又会陷入:怎么漏了?
说白了就是语言缺陷,还有esc中断选择问题,弃疗
aws 发表于 2024-4-15 09:35
这个是真实的工作案例，2700条线，测试两次，一次8秒，一次17秒。
建议采用lee-mac的合并多段线吧，测了2700的图，速度很快只要1秒不到。
cchessbd 发表于 2024-4-17 21:13
建议采用lee-mac的合并多段线吧，测了2700的图，速度很快只要1秒不到。
这么厉害啊，给个链接？或者搜索关键词？
cchessbd 发表于 2024-4-17 21:13
建议采用lee-mac的合并多段线吧，测了2700的图，速度很快只要1秒不到。
找到了，很牛，2700那个，只需要0.14秒。我梳理一下
cchessbd 发表于 2024-4-17 21:13
建议采用lee-mac的合并多段线吧，测了2700的图，速度很快只要1秒不到。
原来如此，找到原因了，他那个把模糊距离给省略了，所以才那么快的。
(command "_.pedit" "_m" sel "" "_j" "" "")
(command "_.pedit" "_m" sel "" "_j" "0.05" "")
这两个差距非常巨大
本帖最后由 aws 于 2024-6-24 15:08 编辑
最终的处理方式：
[*](defun c:jj(/ etime ss stime)
[*](setq ss(ssget '((0 . "*line,arc"))))
[*](if(>(sslength ss)20000)
[*] (progn(alert(strcat "注意：\n选取了"(rtos(sslength ss))"个对象\n已超过设置范围，自动退出！"))(quit))
[*])
[*](setvar "CMDECHO" 0)
[*](setvar "PEDITACCEPT" 1)
[*](setq stime(getvar "MILLISECS"))
[*](vl-cmdf "_.pedit" "m" ss "" "j" "" "")
[*](setq etime(getvar "MILLISECS"))
[*](sssetfirst nil(ssget "p" '((0 . "*line,arc"))))
[*](setvar "CMDECHO" 1)
[*](princ(strcat "\n处理完毕！耗时："(rtos(- etime stime))" ms"))
[*](princ)
[*])
pedit这个命令如果输入模糊距离，对运行速度影响很大，
然后就是人工设置阈值上限，数量特别多的时候，就多合并几次吧
虽然我拿8万条线做测试，但也仅仅是测试，现实场景恐怕也控制在2万条以内。
没了模糊距离，2万条合并，耗时：3281 ms，基本上也不可能会崩溃卡死了。
本帖最后由 cchessbd 于 2024-4-18 12:25 编辑
aws 发表于 2024-4-18 10:47
原来如此，找到原因了，他那个把模糊距离给省略了，所以才那么快的。
(command "_.pedit" "_m" sel "" " ...
你很厉害，原因都让你找出了！确实还有一种支持模糊距离的连接，但是我没时间测试了。平时也不觉得卡。
厉害了，车库配筋计算时，经常有几十万个数值，每次过滤配筋值时卡的都怀疑人生了，和这个比较类似哈