 | |
How wasteful is READV... WRITEV...?
comp.databases.pick comp.databases.pick
 |
| | Thread Tools | Display Modes |
#31
 
| |||
| |||
|
Re: How wasteful is READV... WRITEV...? -
01-30-2010
, 06:02 PM
|
Back to the OP.... On CUBS systems there is (used to be?) a memo file of textual notes; the last note is appended to the end of the memo record as the last attribute, and the number of that last attribute is stored in attribute 1 of the same memo record. CUBS used to use a trick to speed up (circa R83) adding note lines to this file by using a READV + WRITEV + WRITEV which was faster than a standard READ + WRITE, particularly as the number of memo lines increases. Here are two test programs to demonstrate: :ct bp memo.test *(double writev) * * memo.test 001 open "sb.temp" to sb.temp else stop 201,"sb.temp" 002 003 id = "12345" 004 rec = 1 005 t = time() 006 d = date() 007 tot = 10000 008 a0 = @(0) 009 010 write rec on sb.temp,id 011 012 for n = 1 to tot 013 * read rec from sb.temp,id else rec = 1 014 * pos = rec<1> +1 015 * rec<1> * = pos 016 * rec<pos> = "the quick brown fox jumped over the lazy dog" 017 * write rec on sb.temp,id 018 * if mod(pos,100) eq 0 then 019 * * call counter.sub(n,t,d,tot,txt) 020 * * print a0:n:txt: 021 * end 022 next n 023 024 call final.count(n,t,d) 025 :ct bp memo.test2 (single write) * * memo.test2 001 open "sb.temp" to sb.temp else stop 201,"sb.temp" 002 003 id = "12345" 004 rec = 1 005 t = time() 006 d = date() 007 tot = 10000 008 a0 = @(0) 009 010 write rec on sb.temp,id 011 012 for n = 1 to tot 013 * readv pos from sb.temp,id,1 else pos = 1 014 * pos +=1 015 * writev pos on sb.temp,id,1 016 * writev "the quick brown fox jumped over the lazy dog" on sb.temp,id,pos 017 * if mod(pos,100) eq 0 then 018 * * call counter.sub(n,t,d,tot,txt) 019 * * print a0:n:txt: 020 * end 021 next n 022 023 call final.count(n,t,d) 024 And the results.... D3 7.5.1 Linux (with MFT drives!) Regular compile (non-flash) :memo.test 10001 records processed in 00:31 = 323 per second. :memo.test2 10001 records processed in 00:24 = 417 per second. :memo.test 10001 records processed in 00:30 = 333 per second. :memo.test2 10001 records processed in 00:22 = 455 per second. You can see why CUBS did it that way. That was then, this is now; Flash-compiling negates the writev advantage, I guess because of Flash doesn't change the I/O speed but it does radically improve the dynamic array (record) handling. Still, the fact that you can do two WRITEVs in the same amount of time as a single WRITE implies that WRITEV is quite a bit faster. Flash-compiled: :memo.test 10001 records processed in 00:23 = 435 per second. :memo.test2 10001 records processed in 00:22 = 455 per second. :memo.test 10001 records processed in 00:23 = 435 per second. :memo.test2 10001 records processed in 00:23 = 435 per second. Here are the results from a UV/Linux system (I shortened the loop to 3000 on the UV machine to keep the times similar). * RELLEVEL *X *10.2.7 *PICK *PICK.FORMAT *10.2.7 MEMO.TEST 3001 records processed in 00:16 = 179 per second.>MEMO.TEST2 3001 records processed in 00:35 = 85.0 per second.>MEMO.TEST 3001 records processed in 00:16 = 179 per second.>MEMO.TEST2 3001 records processed in 00:35 = 85.7 per second. On this UV system, it looks like two WRITEVs are about twice as slow as a single WRITE, so there does not seem to be any advantage at all to using WRITEV here. /Scott Ballinger Pareto Corporation Edmonds WA USA 206 713 6006 |
#32
| |||
| |||
|
|
Hi Tony Perhaps you should try reading the post to which I was responding which is part of my reponse... |
follow it either.
--
Kevin Powick
#33
| |||
| |||
|
|
Don't worry Tony. Even after this "clarification", I still don't follow it either. |
Perhaps he over-edits his notes and deletes significant words or
sentences.
Perhaps he doesn't read his notes at all before posting to see if they
make any sense - or if they contain factual verifiable details - or if
they contain statements that are easily refuted with a simple Google
search ?
Or perhaps he's prone to visiting this forum after an aperatif and/or
a digestif or two. Personally I wish people wouldn't engage in public
discourse simultaneously with mind altering substances.
Seriously - the first post didn't make sense and then in this last
one, what prompted the outburst about code generation when no one was
talking about that? For the record, BTW, I'm quite fond of code
generators, have blogged about the topic a few times, and spend a good
amount of my daily time writing and using them. I dislike bad code
generators. I don't categorically "hate" code generators - or
anything else.
T
#34
| |||
| |||
|
|
However the major benefit in even that singular scenario is the use of standard variable names. |
Customer(name)
Customer<name>
or perhaps even
readv customer_name from file.customer,customer_code,name else ...
Though for the record, I don't recall having ever used a readv/writev
in "real" code (or even in play things come to think of it)
#35
| |||
| |||
|
|
Hi I am fascinated by the incredible number of opinions expressed here on a totally pointless subject. It is ridiculous to ever use writev or readv as it leads to chaos. The simple rule to follow is always dimension all items as an array and always equate every element of the array to a standard variable then always refer to all variables by name. Simple bug free and obvious. Obviously one sets up a schema for each item and includes it into each program requiring the record. *Then when a file changes as they do overtime it matters not if address1 is now attribute 13 when it was previously attribute 7 Peter McMurray |
|
« Previous Thread
|
Next Thread »
| Thread Tools | |
| Display Modes | |
Linear Mode
| |
Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.