PrimChecks.task.checked对匿名函数的封装导致只需要5毫秒就能调用1e6次的空函数现在需要耗时270毫秒左右
测试JS代码：
//PrimChecks.task.checked=(a,b,c)=>c //这行代码直接干掉task check能让效率提升大约57倍
let f=ProcedurePrims.runString('[->]',!0)
,t=Date.now();
for(c=0;++c<1e6;)f();console.log(Date.now()-t)
系统好像对“;”的识别有问题
function(){
var a=0
a++; console.log(a)
}
总结
js渲染好像没了
可能是因为代码块默认用的NetLogo的高亮
三重反引号后立刻跟’js’就能用js的高亮
例：
console.log('hello world')
@jeremy.baker @Jason, I am forwarding this post to you (simply use the “Globe” button to translate to English). It is related to the NLW performance topic we are discussing here.
能发一个更完整的受影响模型上来吗？方便我们观察性能瓶颈是出在这个点，还是其他地方（有时候单点速度慢并不等于整个模型受影响大，所以我们需要确认这个来知道调整它的优先级。）@maizi20
I just discussed with @maizi20 for a while. It seems that the solution lies in our package system: once we support a package system with the support of raw Javascript extensions (actually, we support it now, so it should be quite easy), those “unsafe” optimizations or proposed syntactic sugar could exist as packages - and relieving us of debating whether a check is good or bad for many possible scenarios. If there are some optimizations that we finally think are worthwhile, we can merge back at any time.
Specifically, custom NetLogo procedures or functions cannot currently accept parameters of variable length. Raw packages should at least support it (in NetLogo Web, it is supported now), and it would be better if NetLogo packages could support them too.
For example, one thing @maizi20 raised was a run-anything primitive that takes both anonymous procedures and reporters. It is hard to do it now in pure NetLogo, since it cannot work with variable numbers of parameters. Once we have the package system, he could simply write a package and import it.
但是netlogo渲染好像寄了