s-m-r-t

Recursive wc on a tree of files

2011-06-09T11:21:00.000-07:00

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.

chrome.send('performClearBrowserData');

2011-03-18T11:27:00.000-07:00

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:

chrome.send('performClearBrowserData');

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?

Visualization of gas prices

2010-02-10T18:45:00.001-08:00

Shows the seasonality of how gas prices fluctuate.

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

2009-11-12T17:29:00.000-08:00

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.

SeAccessCheckWithHint

2009-11-03T17:21:00.000-08:00

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!

First post

2009-08-30T14:57:00.001-07:00

Hello world.