SciFi (15.07.2020 11:44, просмотров: 371) ответил klen на чтоб они выграли все тендэры на модрнизацию ПО на всех комплексах
вооружений. пиндоский хайтек епт.Отчего такой крик души? Выглядит как рабочий момент: https://bugs.chromium.org/p/chromium/issues/detail?id=1102281
ส็็็็็็็็็็็็็็็็็็็็็็็็็༼ ຈل͜ຈ༽ส้้้้้้้้้้้้้้้้้้้้้้้
- I plan to look at telemetry to try to get a rough estimate of the CPU and memory implications of the segment heap in the wild. This is currently difficult to do because I can only compare either M84 to M85 (on WIndows 10 20H1) or else M85 on WIndows 10 20H1 to M85 on other Windows 10. Both options introduce confounding factors, but that's the best that we can do for now.
M85 already has a number of other optimizations and landing this change (simultaneous improvement and regression) at the same time makes comparisons even more difficult.
If we could do A/B testing with our normal mechanisms (i.e.; if we the HEAP_CREATE_SEGMENT_HEAP flag was honored by HeapCreate) then we could do experiments more easily, and we would have the flexibility to use the segment heap preferentially in the process types where it shows the most benefits.
Although I have heard encouraging things about memory savings from lab tests I don't see any way for us to leave this enabled until we have clean telemetry data and lab tests on 20H1, neither of which will be happening in time for M85.
So, the plan is to disable this for M85 (thus giving us another telemetry datapoint) and reconsider in the future.
The CPU cost (10% slowdown on Speedometer 2.0, 13% increase in CPU/power consumption) is too great for us to keep
Reducing the allocation frequency in the renderer tabs may help us get the benefits without the cost (and speed up Chrome generally), but that (along with improvements to the implementation of the segment heap) are long-term projects.
I hope that HeapCreate acquires an option to request (or refuse) the segment heap in the future, for maximum flexibility.