I see the same thing, but the speed is about the same even if
EventMarkerDriver is the only driver being run. So I guess it's just
taking time to read from the file - profiler says
CountedInputStream.read() is the vast majority of the CPU time.
There is definitely a problem, though - the 1.5 release and the February
14 1.6 snapshot (what you can download on
http://lcsim.org/maven2/org/lcsim/hps-java/1.6-SNAPSHOT/) of hps-java run
steering/monitoring/DummyMonitoring.lcsim in 3 seconds, and the current
cvs version runs in 21 seconds. Similar result running on random other
LCIO files with smaller events.
So something happened in the last month. I've filed a bug on Jira.
On Wed, 13 Mar 2013, Hansson Adrian, Per Ola wrote:
> Hey,
>
> I'm running on a file which is filtered for two reconstructed tracks (latest snapshot):
>
> http://www.slac.stanford.edu/~phansson/files/temp/hps_001353.evio.1_twotrkfilt.slcio
>
> When I run the steering/LCIOEventFilter.lcsim over this file on my mac laptop I see a very slow event processing rate ~100Hz. All this is doing is checking for the existence of the track collection, and if its there cut on the nr of tracks and write the event. I checked and it doesn't matter if I write the event or not, still very slow.
>
> What speed do you see for this kind of operation? Any ideas why it's so slow?
>
> /pelle
>
>
> ########################################################################
> Use REPLY-ALL to reply to list
>
> To unsubscribe from the HPS-SOFTWARE list, click the following link:
> https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=HPS-SOFTWARE&A=1
>
########################################################################
Use REPLY-ALL to reply to list
To unsubscribe from the HPS-SOFTWARE list, click the following link:
https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=HPS-SOFTWARE&A=1
|