Topic: Folios non consecutive numbering, new dock collection element

Bonjour,

voici quelques bonnes nouvelles depuis la précédente news.

Hilário a rejoint l’équipe il est charge de la traduction en Brésilien, l'interface est maintenant presque entièrement traduite et activée dans le logiciel.

Davi nous a aussi rejoint comme développeur, il a la charge d'ajouter de nouvelles fonctions aux cartouches, numérotation de composants, etc.

Une nouvelle variable %F, vient d' être ajoutée pour différencier les %{folio-id} des %folio dans la config utilisateur des renvois de folios.

La variable %f  correspond à la variable "%{folio-id}" cartouche : c'est la position numérique du folio dans le projet, cette variable est dynamique et change de valeur à la volée si on déplace le folio dans le projet.
La nouvelle constante %F correspond à un nouveau label "%folio" cartouche statique .

Il est maintenant possible de numéroter des folios avec des règles spécifique :
Ajout de folios non conséquents par leur numérotation, possibilité de numérotation avec des lettres et des caractères */=- +, etc.

Un nouvel outil permet d'ajouter un nombre défini et à la volée de nouveaux folios en utilisant vos paramètres et vos règles de folios.


Dorénavant, vous pouvez spécifier le format des références croisées tout comme les renvois de folios comme bon vous semble. C'est aussi valable pour la numérotation automatique des conducteurs.

https://download.tuxfamily.org/qet/forum_img/XREF_format1.png

Le texte des références croisées acceptent maintenant les noms longs.

https://download.tuxfamily.org/qet/forum_img/XREF_format4.png

Sur le widget information pour renseigner vos éléments, vous pouvez  a ce jour ajouter des variables %f %F %l %c dans vos champs.

L'export vers la nomenclature tient maintenant compte de ces variables.


Le long travail effectué par Joshua pour construire un nouveau panel d’élément est terminé et s'en trouve être très payant.

Ce nouveau dock gère que les collections d’éléments, l'ancien panel la gestion des folios et des cartouches.

Vous pouvez manier les docks comme bon vous semble, empilage des un sur les autres c'est le principe des onglets, les uns en dessous de l'autre, ou alors chaque dock détaché quand vous avez de grands écrans ou config Multi-écrans.

Résultat, la consommation mémoire passe d'environ de plus de plus d' 1 Go de RAM à moins de 30 Mo  au lancement du logiciel avec une collection de 2652 éléments dans 422 categories (soit 3074 fichiers)

... oui oui vous avez bien lu. nomicons/smile

Exemple sur MS Windows :

https://download.tuxfamily.org/qet/forum_img/RAM.png

https://download.tuxfamily.org/qet/forum_img/RAM2.png

L'explication est simple, au lancement aucun Pixmap n'est généré, ils sont crées à la volée au fur a mesure de l'exploration de l'arbre des collections.
Et même avec toute la collection QET dépliée la consommation RAM ne dépasse pas les 300 Mo.

Le temps de lancement de QET s'en trouve aussi très écourté et tombe à ~ 7 secondes sur ma machine.
... et oui, vous avez bien lu. nomicons/w00t

laurent@debian:~$ time qelectrotech

real    0m8.926s
user    0m6.920s
sys     0m0.136s

* Une fois l’édition d'un élément fini il est rafraîchi instantanément dans le panel, prêt à poser sur le folio.
* Les copies de dossier dans les collections sont pareillement instantanées, les éléments sont prêts à être posés sur les folios.
Fini le rechargement des collections avec ce nouveau panel. 

Une fuite mémoire à aussi été résolue grâce à l'expertise de Mehdi.


Enjoy ! nomicons/smile

Re: Folios non consecutive numbering, new dock collection element

Bravo ! <3

Re: Folios non consecutive numbering, new dock collection element

Tu as testé?
C'est quand même le jour et la nuit par rapport à avant surtout sur la consommation RAM.

https://qelectrotech.org/forum/viewtopi … 4603#p4603

Re: Folios non consecutive numbering, new dock collection element

La charge mémoire s'est effectivement bien allégée. Pour la vitesse de démarrage, cela semble plus rapide sur LM17.3 mais pas hyper flagrant : je testerais au boulot sur mon poste WIN7, car c'était vraiment très long, avec en plus le côté pénible du splash screen qui m'empêchait de pouvoir faire autre chose en gardant le focus.

Re: Folios non consecutive numbering, new dock collection element

Oui, l'empreinte mémoire a été divisée par 30 au lancement !
Elle devrait rester assez basse, on n'a jamais le besoin d'ouvrir tous les éléments des collections sur une session.
Quand à la vitesse de lancement ça s’améliore un peu, mais le principe restant le même ce ne sera pas très flagrant.

Re: Folios non consecutive numbering, new dock collection element

Avec la version 4525, juste après démarrage, sans projet:

Post's attachments

v4525.PNG, 124.92 kb, 1176 x 445
v4525.PNG 124.92 kb, 77 downloads since 2016-05-30 

Re: Folios non consecutive numbering, new dock collection element

C'est plutôt divisé par 20... nomicons/grin

Re: Folios non consecutive numbering, new dock collection element

galexis wrote:

C'est plutôt divisé par 20... nomicons/grin

Normal, ça tient aussi compte de ta collection personnelle.
Le temps de lancement de QET sous Windows, mieux, pareil ?

Re: Folios non consecutive numbering, new dock collection element

C'est mieux, sauf au tout premier lancement. Même sous linuxmint.

10 (edited by Joshua 2016-05-30 23:29:27)

Re: Folios non consecutive numbering, new dock collection element

Oui, au premier lancement la bdd est inexistante, donc celle ci est crée et remplis durant le démarrage ce qui effectivement est très long.

Re: Folios non consecutive numbering, new dock collection element

Bon, je prends 5 min pour dire merci concernant l'amélioration de la conso RAM. C'est vraiment une différence phénoménale !

Sur mon Ubuntu 15.10, juste après le démarrage de QET, le moniteur système m'affiche une conso de 37,5MB alors "qu'autrefois", c'était plutôt 900MB voire 1GB. nomicons/blink

Lorsque j'ouvre mon dernier projet avec 137 folios chargé à bloc avec 16 folios nomenclature (sans UUID) et de gros elmt avec des milliers de primitives issus du convertisseur dxf, la conso monte à 1,1GB.

A la fermeture du projet, la conso reste à 1,1GB. Sur Windows 10, en revanche, une partie de la mémoire est vidée, mais ca on connaît, c'est la différence de gestion mémoire entre Windows et Linux.

A la réouverture du même projet, la conso reste calée à 1,1GB alors "qu'autrefois" elle montait déjà à la réouverture du projet (sans fermer QET entre temps).

Par contre, j'ai pas encore fait le test "longue durée" de plusieurs heures de travail car je suis occupé avec un autre projet en ce moment. Mais dès que j'en aurais l'occasion, je surveillerai le comportement de la RAM.

Re: Folios non consecutive numbering, new dock collection element

Une autre différence phénoménale pour te citer Nuri, le lancement et chargement complet de QET est maintenant aussi considérablement réduit. 

QET utilise dorénavant tous les cœurs/threads disponibles du/des processeur(s) de la machine pour gérer le cache SQL des quelques 2600 éléments que contient la collection fournie, le temps de lancement du logiciel et chargement des collections passent maintenant sous la barre des moins de 2 secondes sur ma machine AMD FX 8350 + SDD 840 pro ! nomicons/blink nomicons/smile


https://download.tuxfamily.org/qet/forum_img/RAM3.png

Revision: 4542
Author:   blacksun
Date:     2016-06-06 20:34:34 +0200 (Mon, 06 Jun 2016)
Log Message:
-----------
Use multithreading for loading the element collection

Re: Folios non consecutive numbering, new dock collection element

galexis wrote:

La charge mémoire s'est effectivement bien allégée. Pour la vitesse de démarrage, cela semble plus rapide sur LM17.3 mais pas hyper flagrant : je testerais au boulot sur mon poste WIN7, car c'était vraiment très long, avec en plus le côté pénible du splash screen qui m'empêchait de pouvoir faire autre chose en gardant le focus.

Revision: 4544
Author:   blacksun
Date:     2016-06-06 21:15:31 +0200 (Mon, 06 Jun 2016)
Log Message:
-----------
Remove the flag Qt::WindowStaysOnTopHint of the splash screen

Je doute qu'il t’embête beaucoup maintenant le splash screen, je n'ai même plus le temps de le voir.

Re: Folios non consecutive numbering, new dock collection element

Bon, sous MS Windows c'est clairement pas la même vitesse de chargement escompté dans ma VM seven que sur ma Debian...
Vous confirmez?
Il me semble remarquer que la version ReadyToUse est plus rapide au lancement que celles avec l'installateur .. A suivre !

Re: Folios non consecutive numbering, new dock collection element

scorpio810 wrote:

Je doute qu'il t’embête beaucoup maintenant le splash screen, je n'ai même plus le temps de le voir.

Ben bien les gars, ca valait le coup de faire un splash screen nomicons/wink

Pareil chez moi sous Ubuntu avec l'intel i7-4750HQ, pas le temps de voir le splash. Par contre, le chargement des collections ne se fait plus en arrière plan et je peux maintenant voir la barre de chargement.

Petite différence avec Laurent :
je viens d'installer le dernier build Windows en VM avec Win10. La VM utilisant seulement 2 cores du CPU parmi les 4 disponibles, le chargement est aussi très rapide.
Petite démo :
comparaison démarrage QET sous win10 en VM et Ubuntu en natif

Re: Folios non consecutive numbering, new dock collection element

Merci Nuri, tu me rassures du coup. nomicons/blush
J’étais parti dans de grandes investigations ... , mxe git pull et rebuild des environnements de compilation croisés, recherches aussi du coté de NSIS l'installateur Windows et de mes scripts, voir re installation d'un Seven clean dans ma VM, etc.

Comparaison démarrage QET sous Debian unstable en natif et sous Window 7 en VM.
AMD FX 8350 8C/8T  et dans la VM Seven 6C/6T


Bon ont sait tous que Windows n'est pas réputé pour sa légèreté,  sa stabilité et encore moins pour être un OS rapide, mais là ça commençait à m’inquiéter !


Nuri wrote:

Ben bien les gars, ca valait le coup de faire un splash screen 

Jusqu’à présent oui, aujourd'hui il en serait même superflu suivant les OS et les machines.

Re: Folios non consecutive numbering, new dock collection element

Nuri wrote:

Pareil chez moi sous Ubuntu avec l'intel i7-4750HQ, pas le temps de voir le splash. Par contre, le chargement des collections ne se fait plus en arrière plan et je peux maintenant voir la barre de chargement.

Avant, le chargement de la collection se faisais pendant le splash screen.
À présent, il se fait lors de l'affichage de la fenêtre principal, l'utilisateur voit mieux ce qu'il se passe.

Nuri wrote:

Petite différence avec Laurent :
je viens d'installer le dernier build Windows en VM avec Win10. La VM utilisant seulement 2 cores du CPU parmi les 4 disponibles, le chargement est aussi très rapide.
Petite démo :

Tu me rassure, comme Laurent je commençais à me poser des questions (et en plus installé une VM pour tester sous windows.....).

Le prochain commit sera probablement une amélioration des recherches dans le panel d'élément.
Actuellement quand on cherche par ex omron, le champ bloque bloque sur le o puis mron s'écrit plus tard, y'a quelque secondes ou qet mouline. J'ai mis le doigt sur le problème, bientôt corrigé.

Nuri qu'elle est ton thème d’icône sur ubuntu?
C'est la première fois que je voie une icône de qet dans un thème.

Re: Folios non consecutive numbering, new dock collection element

Bon, le git pull sur le dépôt mxe et rebuild des environnements de cross-compilation aura été quand même payant : le chargement des collections et l'avancement de la barre de progression démarre maintenant de suite sur la VM WIN 7, pas comme sur ma vidéo précédente.
Bon, c'est toujours aussi lent, vais essayer avec une nouvelle VM WIN 10 neuve.


Re: Folios non consecutive numbering, new dock collection element

Nuri wrote:
Petite différence avec Laurent :
je viens d'installer le dernier build Windows en VM avec Win10. La VM utilisant seulement 2 cores du CPU parmi les 4 disponibles, le chargement est aussi très rapide.
Petite démo :

Je ne suis pas convaincu, c'est mieux avec un Win 10 installation neuve, mais c'est tres très loin d’être aussi rapide et fluide qu'une VM XP et dans une moindre mesure un Seven sur le même disque dur que cette VM... pourtant avec 6 cœurs sur 8 alloués ainsi que 8 Go de RAM dédiée à cette VM !

virtualbox-5.0_5.0.20-106931-Debian-jessie_amd64.deb + VBoxGuestAdditions_5.0.20.iso installées !

Re: Folios non consecutive numbering, new dock collection element

@Joshua
j'ai piqué l'icône QET dans le thème "Numix Circle". Sinon, le reste des icônes est un petit mélange de 2 thèmes.

@Laurent
C'est clair que par rapport à QET en natif sous Linux, le démarrage Windows est nettement plus laborieux.

Re: Folios non consecutive numbering, new dock collection element

Faudra attendre les retours de ceux qui l'ont installé sur un Windows natif pour avoir une idée, bien que le facteur core/CPU, HDD/SSD va être déterminant.
Il va de soit qu'on ne va pas revenir en arrière.
Il est clair qu'aujourd'hui qu'avec les dernières améliorations sur la conso RAM, le Multithreading on peut envisager d'importer un nombre très important de symboles dans les collections sans que ça demande une machine  avec beaucoup de RAM installée et un temps de chargement du logiciel très long.

Reste à étudier si on peut améliorer avec le Multithreading l'accélération du chargement de nos gros projets.

Re: Folios non consecutive numbering, new dock collection element

scorpio810 wrote:

Faudra attendre les retours de ceux qui l'ont installé sur un Windows natif pour avoir une idée, bien que le facteur core/CPU, HDD/SSD va être déterminant.

Galexis, et les autres?

Re: Folios non consecutive numbering, new dock collection element

Sous LM17.3 : super rapide.
Pour WIN: je n'utilise que la readytouse, et pas retesté récemment.

Re: Folios non consecutive numbering, new dock collection element

Merci du retour.

25 (edited by galexis 2016-06-10 19:41:01)

Re: Folios non consecutive numbering, new dock collection element

Test rapide sous WIN7 : bien plus rapide qu'avant, splash screen à peine visible. Pendant le chargement de la collection, sur mon pc du boulot bien pourri, il n'était pas possible d'utiliser le soft pendant ce temps là.