Tue, 27 Mar 2007

WD Raptor drives

I'm a big fan of these new WD Raptor 10k rpm SATA drives that have been out for a little while now. So far they've been really solid and they make quite the difference in IO speed. I just replaced a drive in a machine and had a chance to perform a little real world test on identical machines hardware wise except the drive.

Machine A has a Seagate 7200rpm SATA drive (ST380013AS)
Machine B has a Western Digitial 10k rpm 36gig Raptor (WD360ADFD-00)

Both machines are AMD64 3000+ w/1gig of ram (identical mainboards/ram/controllers and whatnot)

First I did a little test with apt-get. Both machines are running Debian Etch and had an identical upgrade to do on firefox (or iceweasel). First I downloaded the packages to make sure they were starting from the same place:
apt-get -d install mozilla-firefox

Next I ran the install and timed them both:
time apt-get -y install mozilla-firefox

For the older seagate drive the time was 22.6 seconds:
real 0m22.571s
user 0m2.956s
sys 0m1.032s


For the 10k WD Raptor it was done in 5.4 seconds:
real 0m5.363s
user 0m1.332s
sys 0m0.496s


If you have the money I'd certainly recommend the Raptor drives as they really do make quite a noticeable difference in anything IO related.

posted at: 15:59 | path: /general | permanent link to this entry


Mon, 05 Mar 2007

speeding up pygtk liststore/treeview

I was running into a problem when populating a pygtk liststore where it would take a rather long amount of time and thus slowed down the app quite a lot. I did some looking into ways of speeding it up and found that the slowdown was a rather expensive sort function I was using (soring by column a, then b, then c, then d). So each time it was adding a row to the liststore it would then run through the sort fucntion to find it's place in the list. So for the liststore I was working with I was adding 379 records and it was taking about 2.5 seconds to populate.

Unfortunately there is no way to disconnect a sort function from a liststore, but you can basicly nullify it by creating a simple sort function that doesn't do anything and tell the list store to use that while you populate, then reconnect the complicated sort function after your done populating so it only needs to run the expensive sort function once instead of 379 times.

sort_func = lambda *args: 0
store.set_sort_func(2, sort_func)
store.clear()
... code to populate store ...
store.set_sort_func(2, self.aisort, (2, 3, 6))


This knocked the time down to 0.12 seconds which makes the app much more usable. I also found you could shave a little more time off by also disconnecting the liststore from the treeview to avoid having to update the treeview when each row is getting updated.

treeview.set_model(None)
... code to populate store ...
treeview.set_model(store)


This got things down to 0.10 seconds which isn't a big improvement but does make a difference. And would account for a bigger differene with more rows of data.

posted at: 18:26 | path: /general | permanent link to this entry


2019-Jun
2019-May
2018-Dec
2018-Jan
2017-Aug
2017-Jun
2017-May
2016-Nov
2015-Dec
2015-Nov
2015-Oct
2015-Jul
2015-Jun
2014-Dec
2012-Oct
2012-Sep
2012-Jun
2012-Feb
2012-Jan
2011-Dec
2011-Sep
2011-Aug
2011-May
2011-Feb
2010-Jun
2010-Apr
2010-Jan
2009-Sep
2009-Jul
2009-May
2009-Jan
2008-Oct
2008-Sep
2008-Jun
2008-May
2008-Jan
2007-Nov
2007-Oct
2007-Aug
2007-Jun
2007-May
2007-Mar
2007-Feb
2007-Jan
2006-Nov
2006-Oct
2006-Sep
2006-Aug
2006-Jun
2006-Apr
2006-Jan
2005-Dec
2005-Nov
2005-Oct
2005-Sep
2005-Aug
2005-Jul
2005-Jun
2005-May
2005-Apr
2005-Mar
2005-Feb
2005-Jan
2004-Dec
2004-Nov
2004-Oct
2004-Sep
2004-Aug
2004-Jul
2004-Jun
2004-May

Powered by PyBlosxom | RSS 2.0