BGAFC Vendégkönyv

Σ: 1 post

TCH (statz)

#1, Főfasz (10443)

3931 | #2cf9 | ^ | Idézet | Sun, 01 Jun 2014 10:41:12 +02

188.36.*.*

*.catv.pool.telekom.hu

@kemi:
A tied persze gyorsabb, mert az csak a libc-re támaszkodik.

Az enyém nem azért gyorsabb, mert csak a libc-re támaszkodik, hanem azért, mert te objektumosan dolgozod fel és annak ekkora overheadje lesz.
A másik viszont nem meglepő, hogy ennyivel lassabb, mind a kettőnél. Gondold végig, az enyém egyszer végigmegy magán a processlisten, olvasgatja a neveket és ha megtalálja amit keresett, akkor kiszáll. A tiéd meghívja a ps-t, ami végigmegy a teljes processlisten, kiolvassa az összes nevet és be is küldi őket a csőbe! Utána még két grep hívás is lesz, amiknek nem egy-egy sort kell parse-álniuk, hanem egy egész listát! És ez is csöveken keresztül megy, ami csak tovább lassítja a dolgot. És akkor azt még nem is kalkuláltuk bele, hogy négyszer is futtatható állományokat kell elindítani (sh, ps, grep, grep).
Σ: Háttértárhoz való nyúlkálás és processzek közti full-text kommunikáció, csöveken. Ergo ez a módszer nagyságrendekkel lassabb lesz, mint egy közvetlenül a memóriából olvasgató for-ciklus.
Azt viszont nem is tudtam, hogy a comm-ba csak a process name van, mindenütt a cmdline-t írták, azt meg parse-lni kell. Így ki lehet egyszerűsíteni az én kódomat is:

#include <dirent.h> 
#include <stdio.h>
#include <string.h>
#include <stdlib.h>

long int get_pid_by_process_name(char *pname)
{
	DIR *d;
	struct dirent *dir;
	FILE *f;
	char entry[24];
	char buf[256];
	size_t l;

	d = opendir("/proc");
	if (d)
	{
		while ((dir = readdir(d)) != NULL)
		{
			strcpy(entry, "/proc/");
			strcat(entry, dir->d_name);
			strcat(entry, "/comm");
			f = fopen(entry, "rb");
			if (f != NULL)
			{
				l = fread(&buf[0], 1, 256, f);
				fclose(f);
				buf[l-1] = 0; /* az utolso byte mindig egy LF! */
				if (!strcmp(pname, &buf[0]))
				{
					return atol(dir->d_name);
				}
			}
		}
		return -1; /* nincs ilyen */
		closedir(d);
	}
	return -2; /* nem lehet megnyitni a /proc-ot */
}

root@Csabi:~/qtproj/build-pidtest-Desktop_Qt_5_3_0_GCC_64bit-Debug# time pidfind_tch

real    0m1.710s
user    0m0.264s
sys     0m1.404s
root@Csabi:~/qtproj/build-pidtest-Desktop_Qt_5_3_0_GCC_64bit-Debug# time pidfind_tch2

real    0m1.785s
user    0m0.280s
sys     0m1.468s

Viszont az a vicc, hogy ez a lassabb bazmeg (~4.5%-al)! Valószínűleg a comm elérése lassabb, mint a cmdline-é. Van rá egy gazdaságos huszasom, hogy azért, mert a cmdline az simán visszaadja azt a memóriaterületet, ahol az adott process indítási parancssora van, míg a comm az kiparse-álja belőle helyettem a processnevet. Ezek szerint sikerült erre a célra gyorsabb parsert írnom, mint ami a Linux kernelben van. :P (Nyilván azért, mert az enyém csak a processnevet keresi meg benne, mással nem foglalkozik.)
Hmm és ráadásul le is van limitálva!

@https://www.kernel.org/doc/Documentation/filesystems/proc.txt:
3.6 /proc/<pid>/comm & /proc/<pid>/task/<tid>/comm
--------------------------------------------------------
These files provide a method to access a tasks comm value. It also allows for
a task to set its own or one of its thread siblings comm value. The comm value
is limited in size compared to the cmdline value, so writing anything longer
then the kernel's TASK_COMM_LEN (currently 16 chars) will result in a truncated
comm value.

Vagyis a comm csak azokat a processneveket adja vissza rendesen, amik rövidebbek, mint 16 byte (mert ugye az utolsó byte mindig egy LF). Nagyon jó... Teszt:

root@Csabi:~# cat /proc/3218/comm
vmware-authdlau
root@Csabi:~# cat /proc/3218/cmdline
/usr/sbin/vmware-authdlauncher

Igen. Vagyis a comm konkéltan használhatatlan, a normális megoldás a cmdline parsingja.