You are not logged in. Please login or register.
QElectroTech → News → Nouveautés de la version de développement 0.8
FYI, The first tests with Qt_for_WebAssembly show that QET can work from a browser on a remote web server but the road is still full of pitfalls
Indeed very interesting!!!
Qt for WebAssembly
WebAssembly is a binary format that allows sand-boxed executable code in web pages. This format is nearly as fast as native machine code, and is now supported by all major web browsers
The build should run on desktop Chrome, and also on Firefox if you enable javascript.options.shared_memory in about:config page.
https://forum.qt.io/category/61/qt-for-webassembly
wasm: prototype file load/save
https://github.com/msorvig/slate/commit … b3a98c5815
This function is used to access local files on Qt for WebAssembly, where the web sandbox places restrictions on how such access may happen. Its implementation will make the browser display a native file dialog, where the user makes the file selection.
https://doc.qt.io/qt-5/qfiledialog.html … ileContent #This function was introduced in Qt 5.13.
https://doc.qt.io/qt-5/qfiledialog.html#saveFileContent #This function was introduced in Qt 5.14.
See this example :
https://msorvig.github.io/qt-webassembl … slate.html
git branch
master
* test_pugi
commit eb903a12b0b904ddc7438f3c699aa4441ea14b38
Author: joshua <joshua@>
Date: Sat Jan 4 15:59:27 2020 +0100
Add option to switch between Qtxml or pugi xml. Add dialog to display the elpsaed time of collection loading.
See : https://qelectrotech.org/bugtracker/vie … d=177#c397
and : https://programmer.group/efficiency-com … idxml.html
Some benchmarks :
Under my Debian Sid devel machine :
Qtxml enable
Le chargement de la collection d'éléments à été éffectué en 798 mspugixml enable
Le chargement de la collection d'éléments à été éffectué en 471 ms
AppImage
Qtxml enable
e chargement de la collection d'éléments à été éffectué en 782 mspugixml enable
Le chargement de la collection d'éléments à été éffectué en 540 ms
commit 3492540d531fbc3d4cd87d498a5403838193027a
Author: joshua <joshua@>
Date: Sat Jan 4 23:33:35 2020 +0100
Use pugixml for parse local name of directory and element informations
further improves launch times especially on MS Windows platform.
Maybe an explanation why it takes longer under Windows VS linux.
https://github.com/Microsoft/WSL/issues … -425272829
Under Windows if you have just started the machine, QET can launch within 9000ms and yes it is much better than before (I saw launch time divided by two), but if you restart the software during the day or in the hour the loading time is much shorter in the order of 4500ms.
J'utilise la version ReadyToUse au bureau sur un PC 32bit en fin de vie: avec Pugi le gain au démarrage est énorme ! Passé de 79s à 13 s !!!
En revanche la fenêtre indiquant combien de temps a été nécessaire au chargement du projet est un peu pénible, il serait intéressant de pouvoir l'inhiber quand les paramètres....
La tu nous fait plaisir : "Passé de 79s à 13 s " prouve que le travail n'a pas été inutile même pour l'OS défenestré.. :p
En revanche la fenêtre indiquant combien de temps a été nécessaire au chargement du projet est un peu pénible, il serait intéressant de pouvoir l'inhiber quand les paramètres....
commit fbec9c9aa51ab96d13fef248e258c1a277bc527e
Author: Laurent Trinques <scorpio@>
Date: Tue Jan 7 13:02:43 2020 +0100
Add Checkbox to enable or disable the dialog to display the elapsed time
of collection loading
J'utilise la version ReadyToUse au bureau sur un PC 32bit en fin de vie: avec Pugi le gain au démarrage est énorme ! Passé de 79s à 13 s !!!
Wahou....
J'ai testé sur deux pc windows
*17s -> 12s soit environ 29% de gain
*11s -> 8 soit environ 26% de gain
Donc pour arrondir, je planchais pour un gain de vitesse de l'ordre de 30% (ce qui est déjà très bien) mais alors la 83%.......
Il me reste encore une amélioration à fignoler.
Sous linux aucun gain de vitesse mais cela s'explique par la manière dont linux gère les accès disque, en revanche sous windows je pense que l'on peut encore gagner du temps.
Dans tous les cas, tous les OS bénéficie de l'amélioration, certains plus que d'autre.
Pour le dialogue qui indique le temps de chargement, c'est temporaire afin d'avoir une mesure, tout comme le fait de choisir entre le parser Qt ou pugi.
Au départ cela devais juste être un petit test pour voir si passer à pugi étais pertinent, mais au vue de l'amélioration et du (relatif) peu de temps que j'ai passé dessus, celui-ci sera intégré pour la 0.8.
Par la suite charger les projets avec pugi devrais aussi être intéressant, mais cela attendra la 0.9.
Disons que sous Linux ça se voit un peu moins, car ça va dix fois plus vite que sous Windows.. le gain est de l'ordre ~ 50% sur ma machine.
Avant commit :eb903a12b0b904ddc7438f3c699aa4441ea14b38
Le chargement de la collection d'éléments à été éffectué en 798 ms
Maintenant avec pugiXml commit : fbec9c9aa51ab96d13fef248e258c1a277bc527e
Le chargement de la collection d'éléments à été éffectué en 347 ms
Pour les 83%, je pense qu'Alexis a testé avec la dernière ReadyToUse ce qui est un peu faux car sur la dernière version avec pugiXml on rallonge les temps si QtXml est utilisé.
Pour être objectif il faudrait comparer les temps sur Windows avec la première version utilisant pugiXml sans l'activer et avec la dernière version en activant pugiXml.
Bon, j'ai viré les paquets de la première version sur le serveur, avant hier... peut-être que Galexis a encore cette ReadytoUse sur sa clé USB pour mesurer le vrai gain réel.
Je pense qu'il peut-être très utile de conserver pour la suite le dialog sur le temps de chargement des collections, ces informations sont toujours très utiles pour les utilisateurs et aussi pour nous.
Je n'ai pas de version plus ancienne de QET contenant pugi. Je suis passé de la git6082 à la git6098 ce lundi.
commit 3d051419a546c5892b5febcaee80352289c9d393
Author: joshua <joshua@>
Date: Thu Jan 9 10:26:10 2020 +0100
Improve file access on windows and mac OSX
//Except for linux OS (because linux keep in cache the file), we keep in memory the xml
//to avoid multiple access to file.
//keep in memory the XML, consumes a little more RAM, for this reason we don't use it for linux to minimize the RAM footprint.
Parser les XML des ~ 6183 elements dans 846 categories (soit 7029 fichiers) est très coûteux en I/O et en temps machine sous Windows, il est plus rapide de tout copier en RAM et les analyser ensuite. Vous comprenez pourquoi la progressBar ne commence qu’après quelques secondes sous Windows.
Je pense qu'on peut aussi gratter encore une ou deux secondes sous Windows avec la version ReadyToUse, forcer les attributs de la collection officielle en lecture seule dans le package plutôt que de le faire à chaque lancement de QET par le fichier.bat, comme les packages Linux. Du style QMAKE_COPY_DIR = xcopy /s /q /y /i /r
Il est clair que certains le font déjà sur leur ReadyToUse pour gratter quelque secondes à chaque lancement de QET, forcer le dossier élément en readonly et supprimer la ligne dans le .bat.
rem Met la collection QET en lecture seule
attrib +r elements/* /S /D
Au niveau des éléments il y a peut être la possibilité de supprimer des doublons ? Sur tout ce qui est symbole pour plan architecturaux notamment il y en a beaucoup.
Ou, on pourrait ne pas charger tous les symboles: perso, les hydrauliques par exemple ne m'intéresse pas. On configureraiy les bibliothèques d'éléments à charger dans les paramètres de QET...
Je connaissais pas l'astuce du readonly.... Si ça peut faire gagner du temps, autant le mettre par défaut vu que la collection est protégée de tout façon....
Non, la collection n'est pas protégée avec la ReadyToUse sinon le .bat n’aurait pas besoin de le faire, mais c'est clair que de le faire a chaque lancement c'est du temps perdu.
Quant a réduire la collection, non ! et c'est ce qui fait la richesse de QET ;-) , certes on a comme dit plus haut un petit nombre d’élément en doublons qui faudrait surement trier.. Sinon avec l'installeur vous avez le choix d'installer ou pas les dossiers éléments dont vous avez besoin, et ne pas cliquer comme un sauvage sur suivant, suivant, suivant, etc ... 
sur la ReadyToUse c'est tres facile de supprimer ou déplacer ailleurs sur vos disques les dossiers éléments de la collection officielle dont vous vous servirez jamais si vous voulez gagner du temps. Pareillement avec l'installeur suffit d'aller dans program\QElectroTech\elements\
En fait même sous Windows les temps de lancement se sont bien réduits, le travail a porté ses fruits, ok ça ce lancera jamais en un éclair comme une bonne machine Linux et un bon SSD ...
Réponse éclairée d'un dev Windows, Cf lien plus haut:
I wish this problem was as easy as saying "NTFS is slow" or "DrvFs is slow". We've long since gotten all the low-hanging fruit and are left with what is essentially "death by a thousand cuts," with no single component responsible for our (lack of) performance, but with lots of different things contributing.
The IO subsystem is architected very differently in Windows than it is in Linux, with different goals in mind. Some of the major differences we have to deal with are:
Linux has a top-level directory entry cache that means that certain queries (most notably stat calls) can be serviced without calling into the file system at all once an item is in the cache. Windows has no such cache, and leaves much more up to the file systems. A Win32 path like C:\dir\file gets translated to an NT path like \??\C:\dir\file, where \??\C: is a symlink in Object Manager to a device object like \Device\HarddiskVolume4. Once such a device object is encountered, the entire remainder of the path is just passed to the file system, which is very different to the centralized path parsing that VFS does in Linux.
Windows's IO stack is extensible, allowing filter drivers to attach to volumes and intercept IO requests before the file system sees them. This is used for numerous things, including virus scanning, compression, encryption, file virtualization, things like OneDrive's files on demand feature, gathering pre-fetching data to speed up app startup, and much more. Even a clean install of Windows will have a number of filters present, particularly on the system volume (so if you have a D: drive or partition, I recommend using that instead, since it likely has fewer filters attached). Filters are involved in many IO operations, most notably creating/opening files.
The NT file system API is designed around handles, not paths. Almost any operation requires opening the file first, which can be expensive. Even things that on the Win32 level seem to be a single call (e.g. DeleteFile) actually open and close the file under the hood. One of our biggest performance optimizations for DrvFs which we did several releases ago was the introduction of a new API that allows us to query file information without having to open it first.
Whether we like it or not (and we don't), file operations in Windows are more expensive than in Linux, even more so for those operations that only touch file metadata (such as stat). The costs of these operations are spread all over the place, from Object Manager and IO manager, to the filters, and NTFS. If it was as simple as saying "NTFS is slow," we'd simply spend a release optimizing NTFS (and we have spent time doing just that), but our costs are so spread out over many components that there just isn't a silver bullet anymore. And we can only ever address in-box filters; who knows what third party filters are doing. We do work with the vendors of those filters to try and improve things. For example, when we introduced the new API to query file information without opening it, we needed filter drivers to support that. We needed to make sure we didn't break the system if some installed filters didn't support it (basically by falling back to a open/query/close operation). Making sure everybody supported this so you, our users, got the maximum speed benefit from that change took a lot of time and effort. The same thing is true for something like the case-sensitive directory work; we had to make sure our filter ecosystem could handle this new behavior.When Rich was talking about app behavior above, he wasn't trying to blame the apps for behaving that way. These apps were written on a system where file system operations are incredibly fast, and we're trying to run them, unmodified (unlike e.g. Git for Windows which tries to optimize its access patterns to better fit the Windows way of doing things) on a system that, unfortunately, is not as fast.
And it's not even as simple as saying "Windows is the cause of the slowness" either, since WSL does play a role. Most notably, Windows path parsing is very different than Linux path parsing (and, as I said above, is the responsibility of the file system, so can differ between file systems, while on Linux it's centralized). Linux apps expect the Linux behavior, so we have to carefully emulate that behavior, and unfortunately that means sending more operations down to the file system. Something like a stat call, which in Linux can be served entirely from the kernel's own cache if you're lucky, for WSL requires sending multiple file system requests, all of which have to traverse the entire filter stack. We've done a lot of work, even as recent as the upcoming 1809, to reduce the amount of extra work WSL has to do. But the differences between Linux and Windows's API mean there'll always be some extra work, at least.
Basically, this isn't a simple problem, and everything we do involves multiple components, and often involves working with Microsoft's partners if the changes affect filter drivers.
That doesn't mean we've given up either. We're still making changes, and are actively exploring new avenues to make WSL faster, and thus more useful, for you. Of course, I wish I could tell you exactly what we're doing and what our timeline is, but that's unfortunately not the corporate reality we live in.
@Galexis : t'as pas essayé de créer un RAMDISK , ça pourrait te faire gagner un peu de temps?
Non, la collection n'est pas protégée avec la ReadyToUse sinon le .bat n’aurait pas besoin de le faire, mais c'est clair que de le faire a chaque lancement c'est du temps perdu.
Quant a réduire la collection, non ! et c'est ce qui fait la richesse de QET ;-) , certes on a comme dit plus haut un petit nombre d’élément en doublons qui faudrait surement trier.. Sinon avec l'installeur vous avez le choix d'installer ou pas les dossiers éléments dont vous avez besoin, et ne pas cliquer comme un sauvage sur suivant, suivant, suivant, etc ...
@Galexis : t'as pas essayé de créer un RAMDISK , ça pourrait te faire gagner un peu de temps?
C'est quoi un RAMDISK ?
Je ne parlais pas supprimer les éléments, mais juste de sélectionner quelles rubriques afficher au lancement et donc lesquelles à charger, sans suppression....
Quelque nouvelles,
-Le chargements des collections d'éléments s’effectue dorénavant grâce au parseur pugixml (le parseur Qt à été définitivement enlever de cette partie du code), le gain de temps lors du chargement est considérable, en revanche je ne peut pas donner de benchmark car cela dépend beaucoup de votre configuration matériel (nombre de cœurs, disque dur vs ssd ....) et de votre OS (Linux en tête), cela dit vous pouvez comptez un minima de 30% plus rapide.
Le revers de la médaille (pour des raisons technique) qet consomme plus de RAM, ~100Mo supplémentaire sous Windows (probablement macOS aussi), puis un peu plus lors de l'utilisation (tout OS confondue) +100Mo sur un projet de 70 pages.
Ce "mauvais coté" pourrais faire l'objet d'un travail afin de diminuer la conso, mais on verra ça plus tard , après tout 200Mo sur nos config actuel....
-En parallèle, le chargement des collections a été retravaillé afin que celui-ci ne freeze plus QElectrotech lors du chargement. Ça ne change rien à la vitesse de chargement, mais c'est plus sympa d'avoir un logiciel qui ne freeze pas.
Good job
ouaip !
Good job.
https://www.qt.io/blog/qt-offering-changes-2020
https://tsdgeos.blogspot.com/2020/01/th … t-lts.html
https://valdyas.org/fading/software/abo … nges-2020/
bonjour.
Un programme de mise à jour logiciel intégré est-il sur la liste?
Ce serait formidable de recevoir des notifications de nouvelles versions
Bonjour,
non, rien n'est prévu dans ce sens pour les paquets de la version dev.
Il y a quelque temps, le nombre de feuilles affichées lors de l'ouverture d'un projet a été remis en question, et la réponse a été d'éviter un bug, la valeur était x3.
Visuellement, ne serait-il pas intéressant de ne montrer que le pourcentage?
Il y a quelque temps, le nombre de feuilles affichées lors de l'ouverture d'un projet a été remis en question, et la réponse a été d'éviter un bug, la valeur était x3.
Visuellement, ne serait-il pas intéressant de ne montrer que le pourcentage?
Si tu peut -être plus clair.
Rasec wrote:Il y a quelque temps, le nombre de feuilles affichées lors de l'ouverture d'un projet a été remis en question, et la réponse a été d'éviter un bug, la valeur était x3.
Visuellement, ne serait-il pas intéressant de ne montrer que le pourcentage?Si tu peut -être plus clair.
Le nombre (% em 81) pourrait être supprimé, affichant uniquement le pourcentage restant pour ouvrir le fichier.
ex_open_file.jpg 38.34 kb, 329 downloads since 2020-02-04
FIY, moved to KVM + QEMU for macOS packaging and upgrade CLANG LLVM compiler.
QElectroTech → News → Nouveautés de la version de développement 0.8
Powered by PunBB, supported by Informer Technologies, Inc.
Generated in 0.037 seconds (16% PHP - 84% DB) with 12 queries