Re: thoughts on meta-data

On Apr 8, 2005 12:10 PM, Wari Wahab <[email protected]> wrote:
> > 11:20 AM /d/code/Python/testfiles$ python test_meta.py
> > test took 0.205000 seconds
> >
> > So there's not really a lot of difference that I see.
> 
> Because you created the files and read them on the spot, you'll see no
> difference. Mine is:
> 
> Vertigo:~/Documents/Work/tests wari$ python testmeta.py
> test took 0.207048 seconds
> 
> If you edit the test_meta to not run make_files(), and wait ten
> seconds, you'll see that the time it takes to read the generated files
> can increase by a factor of two:

I improved the test_meta function, this is faster:

def test_meta(f):
    d = {}
    f = file(f)
    f.readline()
    line = f.readline()
    while line:
        if line[0] != '#': break
        s = line.find(' ')
        d[line[1:s]] = line[s+1:]
        line = f.readline()
    return d

I commented out the makefiles command, and waited 5 minutes:

01:03 PM /d/code/Python/testfiles$ wpython test_meta.py
test took 0.130000 seconds

> 
> Vertigo:~/Documents/Work/tests wari$ python testmeta.py
> test took 0.405119 seconds
> 
> If I tried to optimise test() even further by:
> 
> def test():
>      i = 0
>      totaltime = 0.
>      t1 = time.time()
>      while i < 1000:
>          fname = 'test' + str(i)
>          test_meta(fname)
>          i += 1
>      t2 = time.time()
>      totaltime = t2-t1
>      print "test took %f seconds" % totaltime
> 

This isn't optimizing test(), this is adding the loop, the filename
creating, and incrementing i to the test time. All of these are not
what we are trying to test.

Whether we os.stat or parse for metadata, we need to loop through all
the files, so we shouldn't be testing this.

> I still get about:
> 
> Vertigo:~/Documents/Work/tests wari$ python testmeta.py
> test took 0.301428 seconds

you added at least .1 seconds' worth of stuff to the timing loop, so
that looks about right.

> 
> Anyway, depending on the test platform, results may vary. I believe
> that a system using a drive with 8 MB cache can perform better, for
> example, or if the data buffers is just full of recent drive access.
> 

Absolutely, this test depends on the disk and processor cache when
it's run a bunch of times - I disclaimed these results as unrealistic
each time I gave them.

> Anyway, if I change the test_meta(fname) to os.stat(fname) to compare
> times for a simple call I got:
> 
> Vertigo:~/Documents/Work/tests wari$ python testmeta.py
> test took 0.042642 seconds
> 

test2 is an os.stat on each file, with makefiles commented out.
wpython is a symlink to the windows python, instead of the cygwin
python, on my system:

12:44 PM /d/code/Python/testfiles$ wpython test_meta.py
test took 0.161000 seconds
test2 took 0.050000 seconds
difference: 0.111000
12:44 PM /d/code/Python/testfiles$ wpython test_meta.py
test took 0.150000 seconds
test2 took 0.060000 seconds
difference: 0.090000
12:44 PM /d/code/Python/testfiles$ wpython test_meta.py
test took 0.130000 seconds
test2 took 0.070000 seconds
difference: 0.060000

So, as I see it, the average *benchmark* difference between os.stat()
and reading the metadata is .09 or so (this held true for a bunch more
runs - max .15, min .05, but mostly around the .09 range). Of course,
the IRL values will be different.

> Now, that is what I call a huge difference, not to mention you open the
> file twice, once to read the metadata, and once to parse the data.
> 

We only open the n files to be displayed on this run twice, and who
cares, if the first open is independant of the second? Maybe we could
even store the file handles in the FileEntry objects, which are
already seek()ed to the right place to start parsing?

> Anyway, final mention that NONE of these tests will reflect on real
> world pyblosxom usage, which is mostly co-hosted with everyone else.
> Test on that and results can skew further IMO.
> 

agreed. Is there a good way in cygwin to thrash the disk to clear the
cache? I agree with you that if we want this capability we should
probably keep it in a DB file (I keep it in a pickle in my plugin),
which Will won't do in the core.

However, I *still* think it's worth examining for the core. Especially
if we can save the file handles, already seeked to the right place,
this could be a time savings. .09 seconds is a small enough number to
warrant trying it out in the core to see how it works in the real
world.

Peace
Bill Mill
bill.mill at gmail.com


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click