Tried out Sublime Text 2 Win 64 Bit (2139)While using it i felt the system behaved a little more clogy than usual. After checking the task manager i saw that ST 2 had over 2 million page faults. (http://en.wikipedia.org/wiki/Page_fault) Finding that quite strange i restarted ST2 and the number of page faults was quite reasonable. The instant i started scrolling a simple plain text file (also just 1 tab), the number skyrocketed. I can't think of any reason this should be normal, the only program that i got running that get close (or above) to that number is my anti-virus program and Steam.

Also, it does not only apply to scrolling. Just letting the program idle in the foreground has the same effect, but not so profound.

Page Faults in and of themselves aren't a helpful metric, and don't generally indicate bugs or memory leaks. I'd only be concerned about a large value for Private Bytes, or sluggish user-perceived responsiveness.

jps wrote:Page Faults in and of themselves aren't a helpful metric, and don't generally indicate bugs or memory leaks. I'd only be concerned about a large value for Private Bytes, or sluggish user-perceived responsiveness.

Why i said i could be a possible leak, i don't know if this behavior is intentional or not. Besides it is quite a rampant increase for using basic functions of the software, i found it strange.

In general, any use of large temporary memory allocations will result in page faults. Large memory mallocs / frees will result in 1:1 calls to VitualAlloc/VirtualFree, whereas small memory allocations are coalesced. Memory returned from VirtualAlloc will cause a page fault whenever each page in touched for the first time: initially each page memory is simply added to the virtual address space, but has no physical memory backing it until the page fault is triggered.

Although I haven't looked into it in detail, I'd guess a source of the larger number of page faults you see in Sublime Text comes from the drawing code. Whenever a window is redrawn, a temporary buffer the size of the window is allocated (for double-buffered drawing), which due to its size will usually be allocated via VirtualAlloc (as opposed to using memory in the unallocated portion of the heap), and so will trigger page faults when accessed. The flip side of this is that you get flicker free drawing on Windows, which is not typical of the platform.