Monday, January 20, 2014
Saturday, January 11, 2014
Manually Invoking TRIM To Restore SSD Performance
I've had my SSD for almost two years now and although Intel's SSD utility shows it as having plenty of life remaining, I'd been reading up on TRIM and the details of how SSDs manage their space.
TRIM is a kind of garbage collection for SSDs, for although SSDs don't experience data fragmentation of the sort that hard drives do, there is clutter which can accumulate over time and negatively affect performance.
I found a forum post on "refreshing" SSD performance which mentioned a tiny utility called ForceTrim, which tells your SSD to perform TRIM processing and smooth out the "wrinkles" in its data storage.
Using CrystalDiskMark to benchmark my SSD performance before running ForceTrim, I saw performance close to what it was when I first started using this SSD as my operating system drive:
I then opened ForceTrim, selected my C: drive, and clicked TRIM. As the tool advised, I waited around five minutes for the drive to "recover", then reran the benchmark:
It does appear that manually invoking TRIM can provide a modest boost in read and write performance for an SSD. Perhaps in the SSD age, forcing TRIM once in a while is the "new" defrag?
TRIM is a kind of garbage collection for SSDs, for although SSDs don't experience data fragmentation of the sort that hard drives do, there is clutter which can accumulate over time and negatively affect performance.
I found a forum post on "refreshing" SSD performance which mentioned a tiny utility called ForceTrim, which tells your SSD to perform TRIM processing and smooth out the "wrinkles" in its data storage.
Using CrystalDiskMark to benchmark my SSD performance before running ForceTrim, I saw performance close to what it was when I first started using this SSD as my operating system drive:
BEFORE - Seems pretty close to new SSD performance. |
I then opened ForceTrim, selected my C: drive, and clicked TRIM. As the tool advised, I waited around five minutes for the drive to "recover", then reran the benchmark:
AFTER - Modest gains pretty much across the board. |
It does appear that manually invoking TRIM can provide a modest boost in read and write performance for an SSD. Perhaps in the SSD age, forcing TRIM once in a while is the "new" defrag?
Labels:
performance,
ssd,
TRIM,
windows
Monday, January 6, 2014
Friday, December 27, 2013
LinkButton OnClick Not Firing After OnClientClick
I worked around an oddball problem where the OnClick event of an ASP LinkButton would not fire following execution of some JavaScript tied to its OnClientClick.
The intent is to enable a row in a Telerik RadGrid to be removed by clicking the corresponding button in the row, and more specifically have a modal confirmation dialog appear to prompt the user to confirm their choice.
Here's markup for the GridTemplateColumn containing the button:
The confirmAspButton function is a little JavaScript which is bound to the OnClientClick method of the LinkButton. If the user clicks OK, the confirmation passes and a postback will occur to execute the code beneath the OnClick method, whereas if they click Cancel the dialog will simply disappear.
Seems simple enough, yet for some odd reason, in Internet Explorer 10, the LinkButton brought up the dialog just fine, and although the Cancel button click performed as expected, clicking OK had the same effect as cancel and merely cleared the dialog without executing the underlying code.
I managed to find a workaround via StackOverflow which suggests using a Button rather than a LinkButton. Sure enough, this did the trick, for whatever oddball reason whose particulars I could care less to dive into...
The intent is to enable a row in a Telerik RadGrid to be removed by clicking the corresponding button in the row, and more specifically have a modal confirmation dialog appear to prompt the user to confirm their choice.
Here's markup for the GridTemplateColumn containing the button:
<telerik:GridTemplateColumn HeaderText="Remove" UniqueName="Remove" FilterControlWidth="20"> <ItemTemplate> <div style="cursor: hand;"> <asp:LinkButton runat="server" ID="_RemoveItem" Name="_RemoveItem" Text=" X " Font-Underline="False" ForeColor="DarkBlue" OnClientClick="confirmAspButton(this, 'Are you sure?'); return false;" OnClick="RemoveItemButtonClick" style="font-weight:bold;color:red;"> </asp:LinkButton> </div> </ItemTemplate> <HeaderStyle Width="55"></HeaderStyle> </telerik:GridTemplateColumn>
The confirmAspButton function is a little JavaScript which is bound to the OnClientClick method of the LinkButton. If the user clicks OK, the confirmation passes and a postback will occur to execute the code beneath the OnClick method, whereas if they click Cancel the dialog will simply disappear.
function confirmAspButton(button, message) { function aspButtonCallbackFn(arg) { if (arg) { window.__doPostBack(button.name, ""); } } window.radconfirm(message, aspButtonCallbackFn, 330, 120, null, "Confirm"); }
Seems simple enough, yet for some odd reason, in Internet Explorer 10, the LinkButton brought up the dialog just fine, and although the Cancel button click performed as expected, clicking OK had the same effect as cancel and merely cleared the dialog without executing the underlying code.
I managed to find a workaround via StackOverflow which suggests using a Button rather than a LinkButton. Sure enough, this did the trick, for whatever oddball reason whose particulars I could care less to dive into...
Labels:
ASP.NET,
C#,
internet explorer,
JavaScript,
RadGrid,
Telerik,
workaround
Subscribe to:
Posts (Atom)