yang686526

performance (odamfcapp)
performance (odamfcapp)
hi,
we are using odamfcapp example as basis for a viewer in our applications. we noticed that moving to 2.1.0 the performance of the viewer degraded noticeably.
the old viewer was build with vc6, the new with vc8. i suppose this does not have anything to do with it.
any clues about this?
best regards,
rob van rosmalen
stabiplan bv
hi,
we have some performance reports already, but it will be nice if you attach sample file with time notes. for example ttt.dwg in vc6 release configuration in xx.xx.xx renders about 1sec, but it is about 100 hours in vc8 release configuration in xx.xx.xx.
thanks.
dxf read
if i may jump in here.
i want to highlight the specific case of dxf file reading. in our profiling we saw that for dxf, the preferred method of reading data is thru getbyte() and not getbytes(). an huge number of calls to getbyte() are generated which are even more than the number of bytes in the file. also iseof() is also called a large number of times.
due to the buffering scheme that clients may implement, eof check cannot be optimized beyond a point. can there be a way to reduce this eof calls? and also if more of getbytes() calls are used instead of getbyte() then i think significant performance improvement would be there.
regards,
varun
hi,
did you use profiler with loading functionality ? i am not sure that getbytes\eof are very time consuming operations. our file streams are memory cached, so getbytes\eof are memory reading operations. i think that objects allocation operations & file reading operations are much more time consuming than getbytes\eof. what is a percentage of getbytes\eof in your profiler output ?
getbytes\eof pair are used only in readstring method for dxf loading . number of getbytes calls is around of file size + 1*num of lines in dxf file. number of eof is equal to number of getbytes calls in ideal.
i slightly redesign readstring to decrease number of eof calls and there is no loading time differences before\after test...
sorry if this is the wrong thread for my post. i was not talking about odamfc but our own application. the profilling we used was on our implementation of odstreambuf that we pass in to readfile().
i can't seem to upload files in any format, so i'll mail the zip files containing one set of sample files (dxf and converted dwg) and the timings to . initially we suspected the poor performance due to character conversions, but tests with removing that also yielded almost similar results.
regards,
varun
just sent the file attached with mail titled:
regards,
varun
timing results
hi,
hope i am able to post my attachment. a colleague compared the two viewers and came up with the following results:
current viewer (lib 1.14, vc6 release)
view (open drawing) 8 sec.
zoom window 4sec.
zoom extents 5 sec.
pan 2 sec.
new viewer (lib 2.1.0, vc8 release)
view (open drawing) 8 sec.
zoom window 2 min, 18 sec.
zoom extents 2 min, 59 sec.
pannen 4, 11 sec.
regards,
rob
is it possible that you have gsmodel on in the first case and off in the second?
sergey slezkin
what exactly do you mean? a switch in the code somewhere?
rob