FileExists 的 ColdFusion 速度成本
我想：
- 在每一页上，
- 检查文件是否存在，
- 如果为 TRUE，则包含该文件
，即：
<cfset variables.includes.header = ExpandPath("_inc_header.cfm")>
<cfif FileExists(variables.includes.header)>
<cfinclude template = "_inc_header.cfm">
</cfif>
这是一个好主意吗？
编辑仅使用“_inc_header.cfm”作为模板
替代的实际用途类似于以下 PHP 代码：
foreach (glob("includes/*.php") as $inc) {
require($inc);
}
I want to:
- on every page,
- check if a file exists
- include that file if TRUE
i.e.:
<cfset variables.includes.header = ExpandPath("_inc_header.cfm")>
<cfif FileExists(variables.includes.header)>
<cfinclude template = "_inc_header.cfm">
</cfif>
Is this a good idea?
edited to use just "_inc_header.cfm" as the template
Alternative practical use would be something akin to this PHP code:
foreach (glob("includes/*.php") as $inc) {
require($inc);
}
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
我有同样的问题，因为我有一个包含数百个项目的列表，其中每个项目都与一个或多个文件相关。我想检查每个文件是否存在以进行概述。因为我在这里没有找到答案，所以我在列表中对 FileExists 函数进行了计数，结果是：“7,876 个文件的 FileExits 总执行时间：0.11 秒。”
我认为 FileExits 的速度绝对不是问题。
I had the same question, because I have a list of hundreds of items where each item is related to one or more files. I want to check the existents of each file to have an overview. Because I didn't found an answer here, I tickcounted the FileExists function in my list and the result was: "Total Execution Time FileExits of 7,876 files: 0.11 sec."
I think speed is absolutely no issue with FileExits.
根据流量的不同，性能可能会受到一些影响。
您能否将 include 语句放在 try/catch 中，或者如果失败，也许将检查结果保存在会话中，然后每个会话每个文件检查一次？
Depending on traffic, there could be a bit of a performance hit.
Could you put the include statement within a try/catch or failing that, maybe save the result of the check in a session and then just do the check once per file per session?
我认为更好的方法是检查变量中是否存在标头变量。包含结构：
如果页面不打算使用标头，则在页面代码中删除标头：
i think a better way is to just check for the existence of the header variable in the variables.include structure:
if a page isn't going to use the header then in your page code remove the header:
问题：如何 cfinclude 由
ExpandPath("_inc_header.cfm") 返回的绝对文件路径的文件？无论如何，您的问题听起来应该像“ExpandPath + FileExists 的 ColdFusion 速度成本”，因为每次都会调用两个函数。
如果没有基准测试就无法帮助您，但可以使用类似于 rip747 提出的东西。但我会在某些早期阶段（至少在应用程序启动时，可能在开发过程中）收集可用的头文件，并使用该集合进行检查。集合键可以是当前目录路径，也可以是唯一的分段代码（如果可用）。
Question: how would you cfinclude the file with absolute file path returned by
ExpandPath("_inc_header.cfm")?Any way, your question should sound like "ColdFusion speed cost of ExpandPath + FileExists", because two functions invoked each time.
Can't help you without benchmarking, but it is possible to use something similar to the proposed by rip747. But I would collect the available header files on some early phase (at least at application start, maybe in development process) and used that collections for checking. Collection key can be the current directory path, or maybe unique subsection code if available.
我可能会创建一个名为 application.header 的应用程序变量，并放入标题中的 html 。
然后在每个应用程序中，我可以检查是否已定义以及是否为空。
例如：
在 application.cfm
在您的应用程序页面中。
就这样..
I would probably create an application variable called application.header, and put in the html from the header.
Then in each app, I can check for both isdefined and if not null.
For example:
In application.cfm
In your app page.
And there you go..
我曾经像你一样思考，但我也严格监控我的执行时间。自从更改为每个请求多次调用 FileExists 的系统以来，我注意到加载页面所需的毫秒数有 0ms 的差异。对给定文件的任何频繁查找很可能会导致它被缓存在系统或 SCSI 驱动程序或驱动硬件中的某个位置。 SCSI 硬件上的查找时间更有可能是亚毫秒级的。
鉴于我大量使用 cfinclude，雷达上甚至没有显示另一项查找也就不足为奇了。
事实上，它可能比变量查找有更多的开销，但我们可能谈论的是 0.0001 毫秒的差异，除非您的目录中有数百万个文件，或者您正在 IDE 磁盘上运行网络服务器或类似的愚蠢的事情。额外的代码复杂性可能不值得节省，除非您是/。或者苹果什么的。
对于那些说这是糟糕的建筑的人，我不敢苟同。从中长期来看，您可以购买比开发人员时间便宜得多的处理器。拥有一个只需要更改文件的系统比更改文件和变量更简单 - 并处理额外的复杂性。与优化类别中的大多数事情一样，许多节省一些毫秒的任务可能会占用几个小时，而这些时间本可以用于更有效的措施，例如改进缓存。
I used to think like you do but I also heavily monitor my execution times. Since changing to a system that calls FileExists several times per request I've notice 0ms difference in the milliseconds required to load pages. It's entirely probable than any frequent lookup on a given file will cause it to be cached somewhere in the system or SCSI drivers or drive hardware. It's even more likely that lookup times on SCSI hardware are sub-millisecond.
Given I use cfinclude heavily it's no surprise that one more lookup doesn't even show on the radar.
The reality is it would likely have more overhead than a variable lookup but we're probably talking 0.0001 milliseconds difference unless you have millions of files in a directory or you're running a webserver off IDE disks or something silly like that. The additional code complexity probably isn't worth the savings unless you're /. or Apple or something.
To those who say it's poor architecture I beg to differ. In the mid to long term you can buy processors far cheaper than developer time. Having a system that requires only changing files is simpler than changing files AND variables - and dealing with the additional complexity. Like most things in the optimization category many tasks that save a few MS may occupy hours that could be spent on more effective measures like improving your cache.