多次读取配置文件或使用 gen_server 状态？
我使用 gen_server 和 gen_fsm 实现了一个 otp 系统。有一个配置文件需要读取软件运行所需的某些值，一个示例可能是：
{values, [value1, value2, value3]}.
我使用宏来提取这些值之一
define(VALUES, my_utility:get_conf_value(values)).
问题如下：由于 ?VALUES 可能会经常被调用，因此配置文件被解析很多次，我是否应该将 ?VALUES 嵌入到 gen_fsm 的 gen_server 状态中，并在需要时通过调用提取它？
事实上，我真的很欣赏以前的实现，因为只需更改配置文件内的值即可更改软件的行为，而无需任何 #state{} 更改或调用。
您更喜欢哪种解决方案？
I implemented an otp system using gen_server and gen_fsm. There is a configuration file to be read for some values that the software needs in order to run, an example may be:
{values, [value1, value2, value3]}.
I used a macro to extract one of these values
define(VALUES, my_utility:get_conf_value(values)).
The question is the following: since ?VALUES may be called very often, and therefore the configuration file is parsed many times, should I embed ?VALUES inside the state of my gen_server of gen_fsm and extract it with a call any time I need it?
In fact I really appreciated the previous implementation because one could change the behaviour of the software just by changing the values inside the configuration file, without any #state{} change or call.
Which solution do you prefer?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
解决方案将取决于您的要求。性能与“正确性”。
一种可能的解决方案是将配置保持在进程状态并定期重新读取（检查文件修改时间是否已更改）。这可能是两个世界之间的一个很好的妥协。
摘要：
未考虑的要求：安全性、稳定性（配置文件损坏？）
The solution will depend upon your requirements. Performance vs "correctness".
A possible solution would be to keep the configuration in a process state and re-read it regularly (checking if the file modification time has changed). This might be a good compromise between the two worlds.
Summary:
Requirements not considered: security, stability (corrupt config file?)
这实际上是一个比人们最初想象的要困难得多的主题。例如：
因此，分析您当前的解决方案：
另一个解决方案是将配置存储为代码。例如，您可以有一个特殊的配置模块，您可以使用解析转换或生成实际的源文件来创建该模块。使用此解决方案，配置值驻留在虚拟机的常量池中，获取它们会产生尽可能少的垃圾（取决于您稍后如何处理数据）。
This is actually a topic that is much harder than what one would first think. For example :
So, to analyse your current solutions:
Another solution would be to store the configuration as code. You could for example have a special configuration module, which you create using a parse transform or by generating the actual source file. With this solution, the configuration values resides in the constant pool of the VM and fetching them creates as little garbage as possible (depending on what do you with the data later).
我个人认为最好的解决方案是将配置作为模块进行。好处是：
P.S.：请参阅网络模块加载（又名 nl /1 in shell) 用于集群范围的配置更改。
Personally I think best solution is make configuration as module. Benefits are:
P.S.: See network module load (aka nl/1 in shell) for cluster wide config change.