| Re: [stellation-res] UNITTESTS DROP: support for nested directories |
On Sat, Aug 03, 2002 at 07:04:35PM -0400, Mark C. Chu-Carroll wrote: > > CPU SAMPLES BEGIN (total = 13266) Sat Aug 3 16:58:01 2002 > > rank self accum count trace method > > 1 73.96% 73.96% 9812 233 java.lang.UNIXProcessReaper.run > > 2 25.31% 99.27% 3357 156 java.net.SocketInputStream.socketRead0 > > With IBM's J2RE 1.3.1 IBM build cxia32131-20020410 JDK, the stats are: > > > > CPU SAMPLES BEGIN (total = 7206) Sat Aug 3 17:08:01 2002 > > rank self accum count trace method > > 1 53.26% 53.26% 3838 226 java.lang.UNIXProcessReaper.run > > 2 45.52% 98.78% 3280 148 java.net.SocketInputStream.socketRead0 > > This is pretty much in line with what one sees when using top: during a > > unittest run, the CPU is used in bursts, and there are some inactivity > > periods. > > Remember that this is a client/server system. Watching my system on a > monitor, what I see matches the communication performance pretty > precisely. > > For example, when I do a checkin, I see a burst of CPU activity (the > local workspace code being scanned for changes), followed by a > lull in CPU activity but a major burst of network traffic (changes going > onto the wire), followed by a lull in both CPU and network (changes being > processed by the server), followed by a blip on the network and a burst > on the local CPU (updating the workspace metadata). There is another aspect of this profile info, besides the call of native binaries: all those tests were done with both client and server on the same computer. If the network protocol is so chatty that spends so much time over the local TCP connection (not loopback) then we will be in big trouble when using WAN connections. florin -- "If it's not broken, let's fix it till it is." 41A9 2BDE 8E11 F1C5 87A6 03EE 34B3 E075 3B90 DFE4
Attachment:
pgpE1BFRthopB.pgp
Description: PGP signature