Thursday, June 9, 2011

Recursive wc on a tree of files

Here's how to get the total line count for a tree of files in .

find foldername/ -type f -exec wc -l {} +

The '+' is the key bit, versus '\;' which I think tries to send them one-at-a-time.  Done with cygwin in a windows shell.

Friday, March 18, 2011


So, Chrome 10 has a new HTML-based settings/options page. Good for them, but they really hurt the speed of clearing the cache (see bug 75810). Dozens of times a day, I hit Ctrl-Shift-Del (the cross-browser shortcut for "Clear my cache"), grab the mouse, click the "Clear browser data" button, close the settings tab, then switch back to the tab I care about, to hit refresh.

Trying to bypass the cache never affects javascript files. Ctrl-F5, Shift-F5, whichever, I've tried them all, does not cause Chrome to reload js files.

Digging into the page source of the settings page, I found this line of code:

I've tried to make a bookmarklet out of this, but while "chrome" is a global object the "send" method doesn't appear to be globally defined. Anyone want to make an extension to more quickly (and in a keyboard-friendly way) clear the cache? Or does anyone know of a way to disable/bypass/block the cache in Chrome for development purposes?

Wednesday, February 10, 2010

Thursday, November 12, 2009

Performance of Heap32Next on Windows 7 is linear with heap entry count

Heap32Next is a Windows kernel function used by OpenSSL's rand_win to generate random data via traversing a heap list.

You'd expect such a function to have O(1) performance, wouldn't you?  Nope - not on Win7, at least.  The performance of Heap32Next on any heap entry in heap list is dependent upon the summed number of heap entries in all heap lists.

Here is time taken plotted against the number of heap objects:

You can see that there are jumps which happen to coincide with nice large powers of 2.  Here is the plot of the power-of-two intercepts (represented by the reference lines above), with a linear model fit applied:

Heap32Next Time (ms) = 0.635122*Thousands of Objects on Heap + -56.2174
R-squared: 0.999779

Here's one relevant stack trace:
ntdll.dll!_RtlpWalkHeap@12()  + 0x3f bytes   
ntdll.dll!_RtlpQueryExtendedInformationHeap@16()  + 0x4f5 bytes   
ntdll.dll!_RtlpQueryExtendedInformationAllHeaps@12()  + 0xe5 bytes   
ntdll.dll!_RtlpQueryExtendedHeapInformation@12()  + 0xe7 bytes   
ntdll.dll!_RtlQueryHeapInformation@20()  + 0x1bc76 bytes   
ntdll.dll!_RtlQueryProcessHeapInformation@4()  + 0x288 bytes   
ntdll.dll!_RtlQueryProcessDebugInformation@12()  + 0x11492 bytes   
kernel32.dll!_Heap32Next@4()  + 0x4d bytes   
randwin.exe!RAND_poll()  Line 231 + 0x9 bytes    C++

randwin.exe is my test harness, and sampling indicates that the vast majority of time is spent in RtlpWalkHeap.

Edit: this bug has been filed with Microsoft and OpenSSL.

Tuesday, November 3, 2009


If you're using Process Explorer to grab stack traces in order to narrow down what has gone insanely slow/wrong, and every stack trace bottoms out at SeAccessCheckWithHint (below things like PushLock, SpinLock, WaitFor, and Synchronize), it is NOT the case that your thread is just spinning.  Rather, this is the only time that Windows can jump in to grab the stack.  Look higher!