resource hog -> .asfreq(DateOffset(seconds=1),method='pad')

[mpenning]

>>> df2['a']
2010-12-01 00:00:00    1
2010-12-02 00:00:00    2
2010-12-03 00:00:00    3
2010-12-04 00:00:00    4
>>> df2['a'].asfreq(pn.DateOffset(seconds=1),method='pad')

## NOTE: The above one-liner runs for over 20 minutes on a 2Ghz Xeon, python 2.5.2, numpy 1.5.1,
##       & pandas head from 2011-01-05.  It also consumed > 15% (500MB!!!) of available DRAM
##       before I manually killed it
[mpenning@Bucksnort tickdata]$ free
             total       used       free     shared    buffers     cached
Mem:       3894944    3771540     123404          0     192340    2328984
-/+ buffers/cache:    1250216    2644728
Swap:      2830328        596    2829732
[mpenning@Bucksnort tickdata]$ cat /proc/cpuinfo
...
processor       : 3
vendor_id       : GenuineIntel
cpu family      : 15
model           : 2
model name      : Intel(R) Xeon(TM) CPU 2.00GHz
stepping        : 7
cpu MHz         : 1995.840
cache size      : 512 KB
physical id     : 3
siblings        : 2
core id         : 0
cpu cores       : 1
apicid          : 7
initial apicid  : 7
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 2
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe pebs bts cid xtpr
bogomips        : 3991.51
clflush size    : 64
power management:

[mpenning@Bucksnort tickdata]$

[wesm]

You identified a weakness (which I was aware of) with the way that date ranges are handled-- not a problem for lower frequency data but here it's a problem. I think it's inherently fixable but I need to think about it. I've been thinking recently about using something like Francesc Alted's carray package to implement an efficient (compressed) tickdata data structure-- since tickdata is fairly compressible I expect that it would work quite well.

[wesm]

This ought to be remedied by the datetime64 time in NumPy...once it's arrived. I have some ideas to try to do something about it in the meantime

[wesm]

Not sure exactly how but I appear to have fixed this problem in recent work on DateRange. Note that there's a Second offset in datetools with significantly better performance:

In [5]: s
Out[5]: 
2000-01-03 00:00:00    -1.4477377311
2000-01-04 00:00:00    -0.0657188405266
2000-01-05 00:00:00    -0.240092884503
2000-01-06 00:00:00    0.377959314609

In [6]: %time s.asfreq(DateOffset(seconds=1), method='pad')
CPU times: user 4.68 s, sys: 0.08 s, total: 4.76 s
Wall time: 4.78 s

In [7]: %time s.asfreq(datetools.Second(), method='pad')
CPU times: user 0.33 s, sys: 0.01 s, total: 0.34 s
Wall time: 0.35 s