奇怪的是，在野外禁用焊接会降低JSF的性能
在wildfly 8.x甚至jboss 7.x中，禁用焊接会导致JSF的性能非常低。
在这个问题之前，我讨论了我的性能问题，并通过在standalone.xml中启用weld扩展解决了这个问题
这是我的JSF示例GITHUB（请继续在野蝇上试用）
有人可以向我解释为什么焊接会影响性能吗？
更新：
这里是我的结果，只是为了表明我不是在编造这个
启用焊接
禁用焊接
看到时差了吧！！！！
提前感谢，
特法
共有1个答案
像@ManagedBean这样的JSF注释似乎开始被取代，取而代之的是本问题中讨论的CDI等价物：
支持bean（@ManagedBean）还是CDI Bean（@Named）？
我认为最好将您的代码迁移到CDI，因为WildFly是一个Java7 EE容器，并且WildFly的人很可能决定为CDI等新技术优化他们的容器。
还请查看BalusC在同一帖子中的回答，他很好地解释了这个问题。
-
问题内容： 从MDN文档获取标准功能以及非标准属性 强烈建议不要更改对象的[[Prototype]]，因为它非常慢且不可避免地会减慢现代JavaScript实现中的后续执行，无论如何实现。 使用添加属性是 在 添加成员函数JavaScript类的方式。然后如下图所示： 为什么不好？如果它的坏处不那么坏？ 那么为什么会这样警告：它非常慢并且不可避免地会减慢现代JavaScript实现中的后续执行 。
-
这个问题与现有的问题“使用C11的‘自动’能提高性能吗？” 这个问题的一个答案表明，使用不仅会有积极的影响，也会有消极的影响。 我认为我们需要一个单独的问题，答案集中在自动的那一面。
-
问题内容： 我有这段代码： 如您所见，我仅在columnRendered为true时才渲染该outputPanel。 好吧，在某些情况下（仅用于测试以批准其应做的事情）： 为true，因此应在c：if中输入，并将columnRendered切换为false。但是事实并非如此，因此columnRendered永远是正确的… 你知道为什么吗？ 问题答案： JSF和JSTL不会像您期望的那样同步运行。J
-
TL；DR我们得到bean实例，这些实例注入了另一个会话的内容 最近，我们的两个客户系统出现了严重问题。我们的客户正在两台机器上运行同一个JSF2.2应用程序的两个独立实例，这两台机器有一个Glassfish 4.0服务器和WELD 2.0。5（向内存泄漏致敬！）。 一些用户报告问题，例如提交表单后，响应显示的用户名与最初登录的用户名不同。由于我们无法在开发和测试环境中重现这种行为，我们开始从生产
-
我正在与Node.js和Puppeteer合作，我正在使用Puppeteer刮取多个网站。我正在考虑通过将每个站点实现分离到自己的文件来组织代码。所以我会有like example.com.js example2.com.js等 其中每一个将需要相同的模块（puppeteer/jsdom）并将导出一个包含变量和函数的对象。这样，我就可以在index.js文件中导入所有这些模块。 我读过关于Node
-
null 我们在所有队列（Q和S）中都有挂起的消息，而我们希望它们只在队列S中挂起 当在S中调度的消息唤醒时，它们将移动到T队列：这些消息将根据节流配置(1K消息/秒）进行处理 仍在Q和S中挂起的消息移动到T的速度非常慢（大约50条消息/秒） 如果我们在处理完所有宝贵的消息（再次使用生产者P）后尝试第二轮消息（没有时间窗口），我们仍然以50个消息/秒的速度发送消息，即使在这种情况下，我们根本没有使