如何把选择集分批处理呢？

aws

kozmosovia 发表于 2024-4-15 09:13
画什么图需要用到天天合并8W的线条？就为了偶尔省一下30s，意义不大。

这个是真实的工作案例，2700条线，测试两次，一次8秒，一次17秒。

aws

kozmosovia 发表于 2024-4-15 09:13
画什么图需要用到天天合并8W的线条？就为了偶尔省一下30s，意义不大。

倒也不是为了省30秒，而是为了防止卡死崩溃。

你有种再说一遍

aws 发表于 2024-4-15 09:36
倒也不是为了省30秒，而是为了防止卡死崩溃。

卡死就卡死吧,ssget还容易漏,还是不要考虑什么分区了吧...
如果要分区用ssget你又会陷入:怎么漏了?
说白了就是语言缺陷,还有esc中断选择问题,弃疗

cchessbd

aws 发表于 2024-4-15 09:35
这个是真实的工作案例，2700条线，测试两次，一次8秒，一次17秒。

建议采用lee-mac的合并多段线吧，测了2700的图，速度很快只要1秒不到。

aws

cchessbd 发表于 2024-4-17 21:13
建议采用lee-mac的合并多段线吧，测了2700的图，速度很快只要1秒不到。

这么厉害啊，给个链接？或者搜索关键词？

aws

cchessbd 发表于 2024-4-17 21:13
建议采用lee-mac的合并多段线吧，测了2700的图，速度很快只要1秒不到。

找到了，很牛，2700那个，只需要0.14秒。我梳理一下

aws

cchessbd 发表于 2024-4-17 21:13
建议采用lee-mac的合并多段线吧，测了2700的图，速度很快只要1秒不到。

原来如此，找到原因了，他那个把模糊距离给省略了，所以才那么快的。
(command "_.pedit" "_m" sel "" "_j" "" "")
(command "_.pedit" "_m" sel "" "_j" "0.05" "")
这两个差距非常巨大

aws

最终的处理方式：

• (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

aws 发表于 2024-4-18 10:47
原来如此，找到原因了，他那个把模糊距离给省略了，所以才那么快的。
(command "_.pedit" "_m" sel "" " ...

你很厉害，原因都让你找出了！确实还有一种支持模糊距离的连接，但是我没时间测试了。平时也不觉得卡。

52pj

厉害了，车库配筋计算时，经常有几十万个数值，每次过滤配筋值时卡的都怀疑人生了，和这个比较类似哈