##// END OF EJS Templates
progress: avoid ui.configbool() lookup when progress bar is active...
progress: avoid ui.configbool() lookup when progress bar is active Profiling revealed that the ui.configbool('progress', 'debug') during progress bar updates was consuming a significant amount of overhead. This commit adds an attribute on progress bar instances that caches this config option. The impact on `hg perfprogress` with default options is significant: before: ! wall 4.641942 comb 4.580000 user 4.210000 sys 0.370000 (best of 3) after: ! wall 1.948626 comb 1.950000 user 1.950000 sys 0.000000 (best of 5) After this change, profiling reveals that progress.progbar.progress() is now consuming ~73% of time. This change does not improve the execution time if the progress bar is disabled. We may want a more comprehensive solution for that case, as the progress bar won't be enabled in a number of scenarios (e.g. servers and processes not attached to an interactive TTY). I also think that overhead of ~2.0s for 1M updates is a bit high. I suspect further refactoring of the progress bar can significantly reduce overhead. I don't have plans to do this, however. Differential Revision: https://phab.mercurial-scm.org/D5408

File last commit:

r26284:c258f4d2 default
r41093:6603de28 default
Show More
style-extra-coal.css
46 lines | 608 B | text/css | CssLexer
body {
background: black url('background.png') repeat-x;
}
.container {
padding-left: 0;
padding-right: 150px;
}
.main {
padding: 2em;
border-right: 15px solid black;
border-bottom: 15px solid black;
}
.menu {
background: #999;
padding: 10px;
width: 75px;
position: fixed;
top: 27px;
left: auto;
right: 27px;
}
.menu ul {
border-left: 0;
}
.menu li.active {
font-weight: normal;
background: black;
color: white;
}
.menu li.active a {
color: white;
}
h3 {
margin-top: -.7em;
}
div.description {
border-left-width: 3px;
}