冷熔合速度存在文件成本

根据流量的不同,性能可能会受到影响。

您是否可以将include语句放入try/catch中,或者不执行该操作,或者将签入会话的结果保存下来,然后在每个会话中只对每个文件执行一次检查?

我有同样的问题,因为我有一个数百个项目的列表,其中每个项目都与一个或多个文件相关。我想检查每个文件的存在性以获得一个概述。因为我在这里没有找到答案,所以我在列表中勾选了fileexists函数,结果是:“7876个文件的文件总执行时间:0.11秒。”

我认为速度对于fileexits绝对没有问题。

我认为更好的方法是检查变量中是否存在头变量。include结构:

<cfif structkeyexists(variables.includes, "header")>
  <cfinclude template = "#variables.includes.header#">
</cfif>

如果页面不使用页眉,则在页面代码中删除页眉:

<cfset structdelete(variables.include, "header", false)>

问题:您如何将返回绝对文件路径的文件 ExpandPath("_inc_header.cfm") ?

无论如何,您的问题听起来应该像“coldfusion speed cost of expandpath+fileexists”,因为每次调用两个函数。

如果没有基准测试就无法帮助您,但是可以使用类似于rip747建议的方法。但我会在早期阶段收集可用的头文件(至少在应用程序启动时,可能在开发过程中),并使用这些收集进行检查。集合键可以是当前目录路径,也可以是唯一的子代码(如果可用)。

我可能会创建一个名为application.header的应用程序变量,并从头部放入HTML。

然后,在每个应用程序中,我都可以检查是否已定义以及是否为空。

例如:

应用中.cfm

<cfparam name="application.header=" default="">
<cfset application.header="<img src=/images/logo.png alt='Logo' border=0>" />

在你的应用页面。

<cfif isdefined("application.header") and application.header gt "">

<cfoutput>
#application.header#
</cfoutput>

</cfif>

就这样……

我以前和你一样思考,但我也非常关注我的执行时间。由于改为一个调用文件的系统,每个请求存在几次,我注意到加载页面所需的毫秒数有0毫秒的差异。它完全可能比任何对给定文件的频繁查找都会导致它被缓存在系统、SCSI驱动程序或驱动器硬件中的某个位置。更可能的是,在SCSI硬件上的查找时间低于毫秒。

如果我大量使用cfinclude,那么一次以上的查找甚至都不会显示在雷达上也就不足为奇了。

实际情况是,它可能比变量查找有更多的开销,但我们可能讨论的是0.0001毫秒的差异,除非您在一个目录中有数百万个文件,或者您正在用IDE磁盘运行一个Web服务器,或者诸如此类的愚蠢行为。额外的代码复杂性可能不值得节省成本,除非您是/。或者苹果之类的。

对于那些说这是一个糟糕的建筑的人,我请求不同的意见。从中长期来看,您可以购买比开发人员时间便宜得多的处理器。拥有一个只需要更改文件的系统比更改文件和变量更简单——并且处理额外的复杂性。与优化类别中的大多数内容一样,许多节省几毫秒的任务可能会花费数小时来改进缓存等更有效的措施。