Windows propose beaucoup des fonctions aux signatures complexes sans consistance dans les types ni l'ordre des arguments avec des doublons (tous ces problèmes pour des raisons de compatibilité avec les anciennes versions).
Il y a le même type de problème dans toute API un peu vieille qui continue à évoluer, par exemple POSIX (certes, POSIX n'évolue pas énormément, ce qui est un autre problème...).
il y'a un mélange d'appels systèmes et de fonctions en userland dans l'API Win32 et il n'est pas toujours facile de savoir si une fonction fera un appel système ou non ni quel sera son coût
C'est pas évident sous POSIX non plus (sem_wait, ça fait un appel noyau ou pas ? c'est rapide ou lent ? sous Linux, c'est probablement rapide, sous OS X, c'est probablement lent...). La seule façon sûre de connaître le coût d'un appel, c'est de faire des benchmarks. Après, il y a quelques primitives Windows qui sont documentées comme « rapides » (comme les critical sections).
Exemple typique des avantges du cloisonnement: comment faire un serveur web light avec windows ? Avec linux on peut le faire en 500MB sans problème. Et avec Windows 10 ?
La question est imprécise. Tu veux dire qu'un « serveur Web » (j'imagine un serveur HTTP) nécessite plus de 500 Mo de RAM sous Windows ?
C'est pas difficile de tester, en fait avec Python, ça se fait en un clin d'oeil :
Et hop, voilà un processus servant des requêtes HTTP. Après quelques requêtes depuis mon navigateur envoyé sur l'adresse http://localhost:8000, le gestionnaire de tâches Windows m'indique que le processus Python bouffe 11 Mo. Il y a peut-être quelques structures noyau en plus à prendre en compte, mais je doute que ça atteigne les 500 Mo :-)
Concernant l'optimisation mémoire d'un système Windows tout entier, j'imagine que ça se fait, mais ce n'est pas vraiment mon rayon. Personnellement, j'utilise une VM « de bureau » :-)
[^] # Re: Pas sûr de tout comprendre
Posté par Antoine . En réponse au journal Pourquoi Windows. Évalué à 4.
Il y a le même type de problème dans toute API un peu vieille qui continue à évoluer, par exemple POSIX (certes, POSIX n'évolue pas énormément, ce qui est un autre problème...).
C'est pas évident sous POSIX non plus (
sem_wait, ça fait un appel noyau ou pas ? c'est rapide ou lent ? sous Linux, c'est probablement rapide, sous OS X, c'est probablement lent...). La seule façon sûre de connaître le coût d'un appel, c'est de faire des benchmarks. Après, il y a quelques primitives Windows qui sont documentées comme « rapides » (comme les critical sections).La question est imprécise. Tu veux dire qu'un « serveur Web » (j'imagine un serveur HTTP) nécessite plus de 500 Mo de RAM sous Windows ?
C'est pas difficile de tester, en fait avec Python, ça se fait en un clin d'oeil :
Et hop, voilà un processus servant des requêtes HTTP. Après quelques requêtes depuis mon navigateur envoyé sur l'adresse
http://localhost:8000, le gestionnaire de tâches Windows m'indique que le processus Python bouffe 11 Mo. Il y a peut-être quelques structures noyau en plus à prendre en compte, mais je doute que ça atteigne les 500 Mo :-)Concernant l'optimisation mémoire d'un système Windows tout entier, j'imagine que ça se fait, mais ce n'est pas vraiment mon rayon. Personnellement, j'utilise une VM « de bureau » :-)