Version: 4.4 (using KDE 4.4.5) OS: Linux ksysguardd.c uses an ineffient loop to read from a fd. This causes 1 syscall per byte. Look at the following strace: select(5, [0 4], NULL, NULL, NULL) = 1 (in [0]) read(0, "c", 1) = 1 read(0, "p", 1) = 1 read(0, "u", 1) = 1 read(0, "/", 1) = 1 read(0, "c", 1) = 1 read(0, "p", 1) = 1 read(0, "u", 1) = 1 read(0, "3", 1) = 1 read(0, "/", 1) = 1 read(0, "w", 1) = 1 read(0, "a", 1) = 1 read(0, "i", 1) = 1 read(0, "t", 1) = 1 read(0, "?", 1) = 1 read(0, "\n", 1) = 1 write(1, "CPU 4 Wait Load\t0\t100\t%\n", 24) = 24 write(1, "ksysguardd> ", 12) = 12 Reproducible: Always Actual Results: 231 static int readCommand( int fd, char* cmdBuf, size_t len ) 232 { 233 unsigned int i; 234 char c; 235 for ( i = 0; i < len; ++i ) 236 { 237 int result = read( fd, &c, 1 ); 238 if (result < 0) 239 return -1; /* Error */ 240 241 if (result == 0) { 242 if (i == 0) 243 return -1; /* Connection lost */ 244 245 break; /* End of data */ 246 } 247 248 if (c == '\n') 249 break; /* End of line */ 250 251 cmdBuf[ i ] = c; 252 } 253 cmdBuf[i] = '\0'; 254 255 return i; 256 } Reads from a fd should be buffered.
Dear Bug Submitter, This bug has been stagnant for a long time. Could you help us out and re-test if the bug is valid in the latest version? I am setting the status to NEEDSINFO pending your response, please change the Status back to REPORTED when you respond. Thank you for helping us make KDE software even better for everyone!
Dear Bug Submitter, This is a reminder that this bug has been stagnant for a long time. Could you help us out and re-test if the bug is valid in the latest version? This bug will be moved back to REPORTED Status for manual review later, which may take a while. If you are able to, please lend us a hand. Thank you for helping us make KDE software even better for everyone!
Still the same in ksysguard-5.13.5. A simple strace on the process immediately shows the series of single-byte read() syscalls.
Speaking about inefficiency in ksysguardd, is there an actual reason why it doesn't use Qt's normal means for IO, container implementations etc. and instead uses some home brew structures and algos with questionable efficiency and interfaces?
ksysguardd was written explicitely with minimal dependencies (glibc only) in mind, so that it can be installed on any system to be remotely monitored.
ksysguard is no longer maintained, in Plasma 6 there is the Plasma system monitor for this task. If your issue still happens with the Plasma 6 replacement, please re-open and we can move this bug to the new product, thanks!