Pour moi l'implèmentation de Google n'est pas aussi performante que celle d'Adobe, tout simplement... Google ne fait pas toujours mieux que les autres, même techniquement.

Le Flash intégré dans Chrome (Pepper Flash interface PPAPI) est aussi fourni par Adobe, c'est quasi le même code sauf son interfaçage avec le navigateur. Ca n'est pas Google qui le développe, c'est juste Google qui le distribue.

Comme c'est du PPAPI, c'est plus isolé (sandboxing) et plus sécurisé ce qui explique les différences de performance quand on est au limite de la machine.

Mais ce pas Chrome en soi le coupable. On peut très bien utiliser la version systeme de Flash dans Chrome , la meme que FF utilise, il suffit d'aller dans chrome://plugins/ et désactivé la version PPAPI et s'assurer que la version NPAPI est activée. A ce moment la, on peut vraiment comparer FF et Chrome. Chez moi Chrome va plus vite que FF avec le Flash NPAPI.

C'est l'éternel balance entre performance et sécurité, un choix vite fait dans 99% des cas ( d'autant plus que le Flash PPAPI se met a jour tous seul avec Chrome contrairement a la version system qui ne se met a jour que si on redémarre l'OS).

https://wiki.debian.org/PepperFlashPlayer

La situation pour Linux n'est pas la situation pour les autres OS, il ne faut pas la généraliser. Voir http://www.adobe.com/software/flash/about/

L'accord entre Google et Adobe est un accès au code source du Flash Player, avec d'autres d'ailleurs dont Microsoft pour IE, et à partir de ce source commun, sous le contrôle d'Adobe, Google 'build' et diffuse sa version Pepper et par la même propose donc une version a jour pour Linux alors que celle d'Adobe pour Linux est resté figé a la version 11.

"Google provides newer features in Pepper Flash Player" est donc une généralisation un peu hâtive et une vue réductrice de tout ca. Ce n'est pas Google qui ajoute de nouvelles fonctionnalités dans Pepper Flash, cela n'est que la conséquence de l'utilisation de ce source partagé et a jour. Le Flash est le même partout et sous le contrôle d'Adobe qui fournit (et fait payer) les outils de développement pour faire du Flash. Sinon ca serait vite la zone si chacun ajoute ses propres 'features' dans Flash.

Bref, Ok pour le PPAPI versus NAPI mais pour ce qui est des perfs, ça n'explique pas vraiment tout, surtout du Kernel CPU...

Pour les perfs et le 'kernel CPU usage' il faut comparer a version et type de Flash identiques sinon ça n'a pas vraiment de sens. Qu'est qui n'est pas expliqué la ?

Pour bien analyser, il faudrait aussi le code source en Flash du speedtest...

Le but c'est de mesurer et comparer la vitesse réseau du poste et éventuellement les navigateurs entre eux. Mais faire ca tout en faisant des animations visuelles en Flash c'est bien tant qu'on a que de l'ADSL ou des machines surpuissantes... Il manque vraiment un mode 'sans visuel' dans leur speedtest.

"Pepper" : 14.0.0.177 versus "Adobe" : 14.0.0.145 ... Même version majeure... Mécanisme de sandboxing (peut être bien différent mais existant) aussi avec FF depuis la version 11.3 sous Windows.

Maintenant, avoir les sources en Flash du Speedtest changerai quoi ? C'est du bytecode tout comme pour Java, c'est la FVM qui exécute le même code, et si pour toi Pepper en PPAPI contre Flash en NAPI est à la rue, le problème viendrait donc de PPAPI versus NPAPI... C'est bien joli que Google ait chié sur NPAPI pour proposer un truc moins bien, que personne n'utilise sauf eux, en concurrence avec nACL fait par ... Google et dont la encore tout le monde se fout... un peu comme leur format d'image à la con, par contre pas vraiment le passage limite en force de SPDY (qui n'est pas si joli que ça) dans l'HTTP 2.0.

Si mes trois machines testées, Chrome me claque un overhead de CPU Kernel, et c'est encore plus craint sur une machine peu puissante... Constat final : Chrome bride le test sur DC3 sur mon vieux Core2, pas Firefox. Et c'est de la faute de Google, et que de la sienne...

Comme dit avant c'est comparer des trucs incomparables.

Tu as clairement une dent contre Google donc ca ne sert pas a grand chose d'insister. On est sur lafibre.info ici pas sur universfreebox ou autre site de fanboys. Arguments posés et solides et objectivité sont de mise plutôt que sortir des inepties partisanes.

Si tu veux comparer il faut comparer le comparable: il te suffit de basculer le Flash en mode NPAPI dans Chrome pour faire ca (ca prend 10 secondes et sans redémarrer quoique ce soit). Tu verras que Chrome ne bride rien de plus.
Si tu veux comparer le sandboxing de Pepper et la solution de FF: https://media.blackhat.com/bh-us-12/Briefings/Sabanal/BH_US_12_Sabanal_Digging_Deep_WP.pdf
Oui c'est long (50+ pages) et très technique mais très instructif a lire. C'est écrit par des chercheurs d'IBM et pas de Google ou Adobe et ca ne vient pas d'un wiki lambda et c'est hébergé sur Blackhat.

Encore une fois, oui PPAPI est mois performant que NPAPI pour ce cas (speedtest) mais ca n'est pas un probleme car dans 99% des autres cas car l'écart de performance n'est pas visible vu les utilisations qui sont faites de Flash.

Pour NPAPI vs PPAPI il suffit de se renseigner un peu plus. Aller dire que c'est 'moins bien' juste parce que dans les cas extrêmes c'est plus consommateur de CPU c'est juste complètement partial et partisan. nACL utilise PPAPI et n'est donc pas en concurrence.
Idem pour le format d'image et SPDY, il faut pas sortir ce genre de chose ici sans des arguments fondés et solides , encore un fois on est pas sur universfreebox ou que sais-je.

L'important a savoir serait en dessous de quelles specs matérielles le Speedtest est faussé parce que la machine ne suit pas:

A - la machine ne suit pas dans tous les cas (speedtest en dessous du nominal que ce soit avec Chrome ou FF)
B - la machine ne suit pas uniquement avec PPAPI (speedtest nominal sous FF ou Chrome NPAPI mais pas sous Chrome PPAPI)
C - la machine suit toujours (speedtest nominal avec les 2 navigateurs).

En gros il y a 3 paliers de specs matérielles.
Si l'écart en A et B représente un % ridicule de machines, on parle pour rien depuis le début.
A ce jour j'en ai pas encore croisé de machine dans la tranche B, c'est en général soit A ou soit C.

Donc pour une machine A, que FF affiche 450Mbps au lieu de 950Mbps ou que Chrome affiche 400Mbps au lieu de 950Mbps ca n'apporte pas grand chose a l'utilisateur au final (ni même que Chrome avec NPAPI affiche 500Mbps d'ailleurs).
On ne va pas aller faire installer FF a un néophyte qui a l'habitude de Chrome juste pour ca. Ou lui faire basculer le mode de Flash dans Chrome.

Et pour recoller au sujet de départ de combien les paliers bougent quand on désactive les pubs ?

Quelque chose a fait fortement changer les performances flash sur ma machine sous OpenSUSE 13.2...
Auparavant, il m'était impossible de mesurer un débit supérieur à 30-50 Mb/s sur speedtest.net et surtout sur testdebit.info. Aucun problème en revanche pour atteindre les 100 Mb/s (ou devrais-je dire les 93.43 Mb/s) en ligne de commande ou avec un téléchargement normal.

Mais désormais, ce n'est plus le cas, et ces deux sites affichent 93.43 Mb/s. Difficile de dire exactement depuis quand, comme je ne fais pas un test tous les quatre matins.

Serait-ce une nouvelle version de flash qui se montrerait beaucoup plus véloce ?
Ca me semble surprenant, car je pensais qu'Adobe ne faisait désormais que le strict nécessaire pour le plugin NPAPI (uniquement les corrections de sécurité...)
Pareil du côté de Firefox...

Quelqu'un aurait-il une idée pour expliquer cela ?

cochonou@linux-opensuse-27:~> cat /proc/cpuinfo
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 15
model name      : Intel(R) Core(TM)2 Duo CPU     T7100  @ 1.80GHz
stepping        : 13
microcode       : 0xa4
cpu MHz         : 800.000
cache size      : 2048 KB
physical id     : 0
siblings        : 2
core id         : 0
cpu cores       : 2
apicid          : 0
initial apicid  : 0
fdiv_bug        : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 10
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc arch_perfmon pebs bts aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm lahf_lm ida dtherm tpr_shadow vnmi flexpriority
bogomips        : 3590.94
clflush size    : 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:

cochonou@linux-opensuse-27:~> zypper info flash-player
Loading repository data...
Reading installed packages...


Information for package flash-player:
-------------------------------------
Repository: openSUSE-13.2-Update-Non-Oss
Name: flash-player
Version: 11.2.202.440-2.29.1
Arch: i586
Vendor: openSUSE
Installed: Yes
Status: up-to-date
Installed Size: 19,2 MiB
Summary: Adobe Flash Plugin and Standalone Player
Description:
  This package contains Adobe's Flash Plugin for the supported Web
  browsers in addition to a standalone flash player application.

cochonou@linux-opensuse-27:~> zypper info MozillaFirefox
Loading repository data...
Reading installed packages...


Information for package MozillaFirefox:
---------------------------------------
Repository: openSUSE-13.2 Update-Oss
Name: MozillaFirefox
Version: 35.0-9.1
Arch: i586
Vendor: openSUSE
Installed: Yes
Status: up-to-date
Installed Size: 92,3 MiB
Summary: Le navigateur web Mozilla Firefox
Description:
  Mozilla Firefox is a standalone web browser, designed for standards
  compliance and performance.  Its functionality can be enhanced via a
  plethora of extensions.


Rien que l'affichage du compteur "kilométrique" saccadait beaucoup à l'époque, ce qui n'est plus le cas.
J'avais également contrôlé qu'il n'y avait pas un autre process/daemon qui me consommait des cycles CPU.

Bon, en tout cas je retiens de ta réponse que ça devait donc être un problème spécifique à ma configuration. Et que tout a du retomber "en marche" au cours d'une mise à jour...