View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0021604 | mantisbt | performance | public | 2016-08-14 08:48 | 2020-03-19 12:28 |
Reporter | atrol | Assigned To | |||
Priority | normal | Severity | feature | Reproducibility | have not tried |
Status | new | Resolution | open | ||
Summary | 0021604: Discuss recursive configuration options | ||||
Description | The discussion started as a side note to PR https://github.com/mantisbt/mantisbt/pull/840 atrol dregad
It makes configuration easier for admins, by avoiding the need to duplicate declaration of several related options. Consider the case of paths, or You will probably and rightly argue that we do not need to make the cookies names configurable. Of course by refactoring the code (in the above case, getting rid of these config options), we can implement alternative that works without the recursion. The questions are, whether this is worth the effort and what kind of performance improvement we can obtain by removing this feature.
If this is important to you, I would suggest to open an issue in the tracker, and evaluate how much we'd gain with your proposed approach.
atrol There is a bit less memory usage (removed the caching of the evaled options) and there is about 7% better performance in 2nd benchmark, see results below. Do you think it's worth to think more about it (obsolete cookie seetings, ...) and target it for a version > 2.0? My View 2nd callOriginal master-1.3.x Removed config_eval View Issues 2nd callOriginal master-1.3.x Removed config_eval dregad
7% is not bad indeed, I did not expect that much actually. But keep in mind that in absolute terms, it's still less than 0.02 s gain. I'm still concerned about the loss of "just in time" evaluation of configs however, especially for paths that are quite likely to have been changed by admins - we need to be very careful not to cause regressions. Consider this example: _config_defaultsinc.php
_configinc.php
In this case,
Yes definitely. And get others' opinions too.
For sure a 2.x target, if we decide to move forward. | ||||
Tags | No tags attached. | ||||
0.02 s is not that much, but In best case it means 7% less payment when using CPU based cloud services, or being able to serve 7% more users on the same hardware, or about 2% less power consumption, ... |
|
I have never needed to use recursive configurations, didn't meet the use cases, so i cant provide a precise opinion. However, it has been talked about changing the configuration system in some ways: json based, in-database, hierarchical properties, etc. |
|
It is, but we are not that good in dealing with bigger conceptual changes. |
|
true! anyway, i would not hurry this proposal, if the only benefit is very small If going by the numbers, for my view page: see 0021044 for my measure of 75% gain, or 0020138 for 68% gain in view all page (in my specific instance) |
|