Re: QElectroTech version 0.5 Release Candidate 1 released

Visiblement, il y a un truc dans le code qui ne vide pas la RAM. Je pense peut-être au bouton "recharger les collections" dont je me suis beaucoup servi aujourd'hui.

Clair, je viens de tester sur de mes vieux projet de ~115 folios : à chaque action sur la touche F5 (recharger les collections) la RAM utilisée peut augmenter de plus 100 à 200MIo à chaque fois.

https://download.qelectrotech.org/qet/forum_img/ram.png

https://download.qelectrotech.org/qet/forum_img/ram1.png

Le problème est connu, surtout lors du premier lancement de Qet ou la génération de la base de donnée des miniatures peut consommer plus d'un 1.5GIo de ram avec une collection de ~2600 éléments, pareillement quand on change la langue du programme et donc aussi des elements. Il est d'ailleurs conseiller de fermer et de relancer Qet dans ces cas!

"Le jour où tu découvres le Libre, tu sais que tu ne pourras jamais plus revenir en arrière..."

Re: QElectroTech version 0.5 Release Candidate 1 released

Rien à voir: j'ai remarqué que lorsqu'on ouvre un projet existant et qu'on ajoute un folio, on ne peut pas enregistrer le projet, le bouton est grisé.
De même avec le déplacement de folio.

Re: QElectroTech version 0.5 Release Candidate 1 released

@Nuri :
Pense à faire des pauses, sauvegarder et fermer Qet, prendre l'air, ou en griller une ! nomicons/tongue
Je sais bien que dessiner avec Qet est prenant, mais 7 heures d'affilées c'est pas un peux trop?

"Le jour où tu découvres le Libre, tu sais que tu ne pourras jamais plus revenir en arrière..."

Re: QElectroTech version 0.5 Release Candidate 1 released

galexis wrote:

Rien à voir: j'ai remarqué que lorsqu'on ouvre un projet existant et qu'on ajoute un folio, on ne peut pas enregistrer le projet, le bouton est grisé.
De même avec le déplacement de folio.

Normal, la gestion des folios n'est pas encore ajouté à la pile historique : donc ajouter un folio vide, déplacer des folios et rien d'autre, le programme ne voit aucun changement donc l'icone idoine reste grisée.
Par contre tu peut enregistrer sous : et écraser l'ancien.

"Le jour où tu découvres le Libre, tu sais que tu ne pourras jamais plus revenir en arrière..."

Re: QElectroTech version 0.5 Release Candidate 1 released

2.
Un petit problème de rafraichissement :
Dans les propriétes du folio, les cases à cocher "afficher les en-têtes" ne fonctionnent plus à la volée. Il faut qu'il se passe quelque chose dans la vue de l'éditeur de schéma pour que les en-têtes prennent en compte la nouvelle valeur des cases à cocher.

Je ne constate pas ce problème chez moi !
Par contre j'y pense, tu es toujours avec la lib libqt5core5a en 5.5.1  de Debian Sid installé à la sauvage sur ton Ubuntu 15.10 en Qt 5.4 ? nomicons/tongue

Je conçois que Qet est pas encore parfait avec la gestion de la RAM sur le cachedb, mais la c'est carrément une grosse fuite mémoire ... ou de mitrailler la touche F5.

J'ai déja passé plus de 5 heures consécutives en dessin de schéma, et pas remarqué cette explosion de ram utilisée, surtout limité par les 2GIo de ram sur le vieux pc au taff, le swap aurait ralenti la machine..et le kernel aurai fini par killer le process Qet..

"Le jour où tu découvres le Libre, tu sais que tu ne pourras jamais plus revenir en arrière..."

Re: QElectroTech version 0.5 Release Candidate 1 released

scorpio810 wrote:

Pense à faire des pauses, sauvegarder et fermer Qet, prendre l'air, ou en griller une !

J'en grille déjà assez comme ca !

scorpio810 wrote:

Je sais bien que dessiner avec Qet est prenant, mais 7 heures d'affilées c'est pas un peux trop?

ben quoi, c'est mon boulot :-)
Quand j'ai fait les plans au printemps, c'était parfois 10 ou 11 heures par jours...

scorpio810 wrote:

Par contre j'y pense, tu es toujours avec la lib libqt5core5a en 5.5.1 de Debian Sid installé à la sauvage sur ton Ubuntu 15.10 en Qt 5.4 ?

Nan nan ! Sur tes conseils, j'ai tout dégagé au plus vite avant que mon cher Ubuntu ne se transforme en Win98...
Bon, comme d'hab, ca m'a couté quelques gouttes de sueurs (Qt Linguist qui marche plus, le VLC player qui fout le camp, Qt Creator qui veut pas ouvrir les .pro, Compiz qui fait des galipettes...) puis finalement tout rentre dans l'ordre. Comme quoi, Linux c'est quand même bien pensé : même avec un neuneu aux commandes, le système retombe toujours sur ses pattes.
Mon install date de la 14.04. Depuis, j'ai fait 3 dist-upgrade et le système tient toujours le coup. Ils sont forts, c'est presque de la rolling release maintenant...

scorpio810 wrote:

J'ai déja passé plus de 5 heures consécutives en dessin de schéma, et pas remarqué cette explosion de ram utilisée, surtout limité par les 2GIo de ram sur le vieux pc au taff, le swap aurait ralenti la machine..et le kernel aurai killer le process Qet.

Avec 16GB de RAM, je me suis dit que j'avais pas besoin de swap...nomicons/whistling

Georges Brassens wrote:

"Quand on est con.... on est con..."

scorpio810 wrote:

Je conçois que Qet est pas encore parfait avec la gestion de la RAM sur le cachedb, mais la c'est carrément une grosse fuite mémoire ... ou de mitrailler la touche F5.

J'ai rajouté des données aux éléments de la collec embarquée, fait la traduction en anglais, switché entre allemand/anglais, reloadé les collections un bon paquet de fois (mais c'était pas encore du mitraillage)...
Cependant, y'a quand même quelque chose de louche. La conso RAM montait vraiment vite.
Tant pis si ca peut pas être réglé pour la 0.5 mais ca doit pas être que du bonheur sur les petites machines.

Re: QElectroTech version 0.5 Release Candidate 1 released

Et concernant le problème des en-têtes (avec QET svn4266), voici donc le problème illustré en vidéo :

vidéo

Re: QElectroTech version 0.5 Release Candidate 1 released

Nuri wrote:

Et concernant le problème des en-têtes (avec QET svn4266), voici donc le problème illustré en vidéo :

vidéo

video

"Le jour où tu découvres le Libre, tu sais que tu ne pourras jamais plus revenir en arrière..."

Re: QElectroTech version 0.5 Release Candidate 1 released

nuri wrote:

Nan nan ! Sur tes conseils, j'ai tout dégagé au plus vite avant que mon cher Ubuntu ne se transforme en Win98...
Bon, comme d'hab, ca m'a couté quelques gouttes de sueurs (Qt Linguist qui marche plus, le VLC player qui fout le camp, Qt Creator qui veut pas ouvrir les .pro, Compiz qui fait des galipettes...) puis finalement tout rentre dans l'ordre. Comme quoi, Linux c'est quand même bien pensé : même avec un neuneu aux commandes, le système retombe toujours sur ses pattes.
Mon install date de la 14.04. Depuis, j'ai fait 3 dist-upgrade et le système tient toujours le coup. Ils sont forts, c'est presque de la rolling release maintenant...

Mon installation date de plus de 7 ou 8 ans si ce n'est pas plus...et encore c'étais pour passer du 32 au 64 bits et toujours en Debian Sid.
Elle à traversée plusieurs changements de disque dur depuis jusqu'à maintenant avec le SDD 840 pro, sans ré installation, avec un Système qui roxe tous les jours, et en rolling release.


nuri wrote:

Avec 16GB de RAM, je me suis dit que j'avais pas besoin de swap... 

Regarde ma capture : je n'en ai pas non plus, et parfois je suis à l’étroit avec mes 16G!


nuri wrote:

J'ai rajouté des données aux éléments de la collec embarquée, fait la traduction en anglais, switché entre allemand/anglais, reloadé les collections un bon paquet de fois (mais c'était pas encore du mitraillage)...
Cependant, y'a quand même quelque chose de louche. La conso RAM montait vraiment vite.
Tant pis si ca peut pas être réglé pour la 0.5 mais ca doit pas être que du bonheur sur les petites machines.

C'est le switch régulier "allemand/anglais " le coupable, essaye tu comprendras. nomicons/smile
On empile en Ram à chaque fois que tu switch de langage et que tu reload la collection.

Sur les petites machines suffit de fermer Qet et de le relancer quand on change de langue, en fait c'est pas prévu de changer la langue des éléments à la volée très fréquemment, comme tu t'en ais aperçu !

"Le jour où tu découvres le Libre, tu sais que tu ne pourras jamais plus revenir en arrière..."

Re: QElectroTech version 0.5 Release Candidate 1 released

Pour la conso ram (qui est un vrai problème) je suis entrain de me pencher dessus.
Alors déjà il est claire que ce sera pas pour la 0.5.
Ensuite, je lie beaucoup de doc Qt pour résoudre le problème, je pense avoir trouvé la solution (et si c'est le cas, ce sera une solution pérenne) mais il y aura beaucoup de boulot.
Donc une grande partie du développement de la 0.6 se portera dessus. Il est possible (conditionnelle: j'ai peut être tort) que suite à ce changement le démarrage de qet soit plus rapide qu'actuellement.

Développeur QElectroTech

Re: QElectroTech version 0.5 Release Candidate 1 released

Le démarrage on s'en fout un peu Joshua : surtout maintenant avec les sdd sata, avec les ssd PCI-Express NVMe ça devrait aller encore plus vite, si on ajoutent la gestion des threads sur le cachedb pour exploiter tous les cores cpu:  le premier chargement des collections n'en sera que plus rapide, en principe.
Une fois le cache pixmap (cachedb) déjà à jour, le lancement de Qet complet prend dans les 7 secondes sur cette machine.

[05:03:11] laurent@debian:~$ time qelectrotech
transaction began for  "common"
transaction commited for  "common"
transaction began for  "custom"
transaction commited for  "custom"

real    0m7.007s
user    0m4.704s
sys     0m0.496s

C'est le chargement des gros projets en mémoire (+ 500 folios) qui en seraient fortement accélérés, avec une consommation mémoire grandement divisée, avec ta solution, si tu y arrives.

Exemple :lancement de Qet, et chargement d'un projet de ~120 folios assez lourd : (multiples images, très nombreuses définitions de symboles, plusieurs milliers d’éléments), un seul core est actif, avec la gestion du multithread  on gagnerai sur les temps de chargement: ~40 secondes (lancement de Qet et du projet ~ 120 folios : jusqu’à être prêt à dessiner) sur la machine de build. Sur une machine moins musclée, ça prend effectivement beaucoup plus de temps.


[05:03:30] laurent@debian:~$ time qelectrotech
transaction began for  "common"
transaction commited for  "common"
transaction began for  "custom"
transaction commited for  "custom"


real    0m39.601s
user    0m33.668s
sys     0m1.168s

https://download.qelectrotech.org/qet/forum_img/ram3.png
Je vous faits grâce des acces disques 

"Le jour où tu découvres le Libre, tu sais que tu ne pourras jamais plus revenir en arrière..."

Re: QElectroTech version 0.5 Release Candidate 1 released

Nuri wrote:

Et concernant le problème des en-têtes (avec QET svn4266), voici donc le problème illustré en vidéo :

vidéo

Pas de problème chez moi, sur LM17.2.

38 (edited by Nuri 2015-11-20 11:35:18)

Re: QElectroTech version 0.5 Release Candidate 1 released

Concernant le problème de RAM, je viens de constater un truc :
J'ai fini la traduc en anglais de mon projet, j'exporte la nomenclature en csv, je fais tourner ma macro LibreOffice qui me crée 7 nouveaux elmt contenant les tableaux de nomenclature.
Je retourne sous QET, recharge les collections et la conso RAM augmente d'environ 100MB (ca on le savait déjà).
Puis, je crée les nouveaux folios pour tirer/déposer les elmt de nomenclature. Et là, à chaque elmt insérer, c'est environ 50 à 100MB de conso RAM en plus. Bizarre, car les elmt de nomenclature pèsent même pas 90KB.
Pour essayer, je tente alors l'expérience suivante :
j'efface tous les elmt nomenclature de mon projet, je nettoie le projet et j'enregistre. La conso RAM baisse légèrement (max. 50 à 100MB en moins). Puis je réinsère mes elmt nomenclature et c'est à nouveau 50 à 100MB de conso RAM en plus à chaque tableau insérer (qui s'ajoute à la conso RAM précédente). Et ainsi, en esseyant plusieurs fois, comme hier, j'ai vite atteint 10 voire 12GB de conso RAM

Conclusion provisoire :
la gourmandise de RAM n'est pas provoquée exclusivement par "recharger les collections", il y a un truc encore plus glouton là derrière...

Edit :
heu... j'avais oublié que cela provient vraisemblablement de la création des pixmaps des elmt nomenclature (vu que ce sont des éléments avec une surface énorme).

Re: QElectroTech version 0.5 Release Candidate 1 released

Je viens d'essayer avec tes éléments nomenclature sur un projet vide :

RAM utilisée au départ ~850Mio.
Je pose tes 7 éléments
RAM utilisée à la fin ~ 1,5Gio

Edit : plus l’élément est complexe, plus la ram utilisée sera élevée, après tu peux le poser indéfiniment ça ne montera presque pas.

Une fois le projet ré ouvert la Ram utilisée retombe à 1.1Gio.

"Le jour où tu découvres le Libre, tu sais que tu ne pourras jamais plus revenir en arrière..."

40 (edited by Nuri 2015-11-20 12:18:40)

Re: QElectroTech version 0.5 Release Candidate 1 released

ben, ok Laurent, mais ce que je ne comprends pas, c'est pourquoi un elmt qui pèse 90KB fait augmenter la conso RAM d'un facteur 1000 (quasiment) une fois qu'il est dans le projet .qet nomicons/blink

Re: QElectroTech version 0.5 Release Candidate 1 released

Au sujet de la ram qui grimpe abusivement j'ai peut être une idée.
Lorsque habishek à crée l'export en dxf, il à fait un truc que je trouve pas top.
Quand on crée un pixmap d'élément en fait on "dessine dessus".
Pour dessiner on utilise des forme simple (ligne, ellipse, rectangle tec....), abishek garde ces formes en mémoire pour chaque élément afin de s'en servir lors de l'export en dxf et je pense que cela consomme pas mal de ram, et c'est proportionnel au projet. Ce qui aurais été bien pour l’export c'est plutôt de lire la description dans le xml puis le convertir en dxf, ainsi y'a pas de conso ram supplémentaire, en gros c'est dxf-to-qet dans l'autre sens.
Dans ton cas nuri, je suppose que tes tableaux sont remplis de texte et de rectangles ou lignes, chaque primitive étant gardé en mémoire, ça grimpe vite.
Je peut vous faire un petit patch ou l'on ne garde pas en mémoire chaque primitives, pour voir si ça va mieux.

Développeur QElectroTech

Re: QElectroTech version 0.5 Release Candidate 1 released

C'est le switch régulier "allemand/anglais " le coupable, essaye tu comprendras. 
On empile en Ram à chaque fois que tu switch de langage et que tu reload la collection.

Une bois les caches crées Anglais, Allemand, français, et à jour . Apres un reboot de Qet : switcher d'un langage à l'autre ne consomme pas plus de RAM.

"Le jour où tu découvres le Libre, tu sais que tu ne pourras jamais plus revenir en arrière..."

Re: QElectroTech version 0.5 Release Candidate 1 released

Joshua wrote:

Je peut vous faire un petit patch ou l'on ne garde pas en mémoire chaque primitives, pour voir si ça va mieux.

A toi de voir où tu poses tes priorités : soit la sortie de la 0.5 finale, soit le patch. C'est peut-être un peu aventureux de faire un tel patch juste avant la sortie de la 0.5. A mon avis, on aura pas assez de recul pour voir si le patch ne crée pas de nouveaux problèmes.

Joshua wrote:

Dans ton cas nuri, je suppose que tes tableaux sont remplis de texte et de rectangles ou lignes, chaque primitive étant gardé en mémoire, ça grimpe vite.

ouais ok, mais là on parle d'environ 100MB pour un elmt. Quelque part, l'ordre de grandeur n'est pas juste. A la rigueur, 5 ou 10MB je veux bien, mais pas 100. Ca semble beaucoup trop.
Compare avec une video MP4 en HD 1080p d'une minute, ca fait combien de MB ?!?

Scorpio810 wrote:

Apres un reboot de Qet : switcher d'un langage à l'autre ne consomme pas plus de RAM.

Oui, de toute facon, pour avoir toute la GUI dans une nouvelle langue, il faut redémarrer QET, ce qui vide la RAM. Donc le problème ne vient pas de la gestion des langues.

Pour résumé le topo :
ce qu'on savait déjà, c'est que QET ne gère pas de facon optimale la conso RAM lors de la création des pixmaps et de la recharge des collections.
Ce qui est peut-être nouveau, c'est une haute (voire très haute) conso RAM lors de l'insertion de elmt de type nomenclature contenant beaucoup de primitives.

Re: QElectroTech version 0.5 Release Candidate 1 released

Pour le patch, c'est pas pour l’intégrer dans la 0,5 car il y aurais beaucoup plus de boulot.
C'est juste pour vous afin d'essayé avec vos projet, et si la conso ram baisse alors sa m'aiguille sur l'origine du problème.

Bon le comparatif avec une vidéo bof, une vidéo est compressé avec des algos très très complexe, alors que dans qet rien n'est compressé. Cela dit, j'avoue que garder en mémoire des QLineF, QRectF et compagnie ça doit pas prendre des quantité astronomique de ram.

La 0,6 sera orienté sur ce problème qui deviens de plus en plus contraignant.

Développeur QElectroTech

Re: QElectroTech version 0.5 Release Candidate 1 released

Il n'y a pas que ça, sqlite pourrais aussi en être la cause :
http://www.qtcentre.org/threads/31287-Sqlite-Memory-Use

Faut que je fasse des tests pour connecter un PostgreSQL, ou un autre SQL sur le cache pixmap pour voir.

"Le jour où tu découvres le Libre, tu sais que tu ne pourras jamais plus revenir en arrière..."

Re: QElectroTech version 0.5 Release Candidate 1 released

Ce qui est peut-être nouveau, c'est une haute (voire très haute) conso RAM lors de l'insertion de elmt de type nomenclature contenant beaucoup de primitives.

Ça dépend, fais le test avec une VM limitée en RAM, exemple 2Gio, tu verras que le noyau gère ça très bien.
Sur un vieux pc avec 2Gio de RAM j'ouvre deux gros projets (que tu connais), sans dépasser les 1.5Gio de Ram utilisée et très peu en swap (200Mio..)!
Sur la worksation il va en surement en prendre plus au fur à mesure, car 13Gio de libre il va en profiter.
Le noyau plus il voit de RAM, plus en utilise si le besoin s'en fait ressentir, c'est pas nouveau, les débutants linuxiens s'en affolent à chaque fois.
A quoi ça sert d'avoir autant de RAM si ce n'est pour pas l'utiliser, le noyau s'en sert, pas comme sous Windows...ou même avec beaucoup de RAM, il va swaper comme un porc, tu te demandes bien ce qu'il écrit en permanence sur le disque dur.... nomicons/tongue

"Le jour où tu découvres le Libre, tu sais que tu ne pourras jamais plus revenir en arrière..."

Re: QElectroTech version 0.5 Release Candidate 1 released

Nuri wrote:

ben, ok Laurent, mais ce que je ne comprends pas, c'est pourquoi un elmt qui pèse 90KB fait augmenter la conso RAM d'un facteur 1000 (quasiment) une fois qu'il est dans le projet .qet nomicons/blink

un elmt c'est juste une définition en XML d'un format qui se rapproche du SVG, après il y a toute la conversion avec le painter dans la scène graphique avec des traitements graphique qu'on lui demande d’exécuter en plus ou moins suivant le rendu souhaité, le tout stocké en RAM:
Quelques exemples :
p -> setRenderHint(QPainter::Antialiasing, false);
p -> setRenderHint(QPainter::TextAntialiasing, true);
p -> setRenderHint(QPainter::SmoothPixmapTransform, false);

QPainter p(&preview);
p.setRenderHint(QPainter::Antialiasing, true);
p.setRenderHint(QPainter::SmoothPixmapTransform, true);
// Translation de l'origine du repere de la pixmap
p.translate(hotspot_coord);
// L'element se dessine sur la pixmap
paint(&p, 0);


pen.setWidthF(0.4);
pen.setCosmetic(true);
pen.setColor(Qt::darkGray);



// utilisation d'un trait "cosmetique" en-dessous d'un certain zoom
if (options && options -> levelOfDetail < 1.0) {
final_conductor_pen.setCosmetic(true);

Dans le même style : un fichier DWG de 77Kio, si tu le convertis en DXF il pèse maintenant plus de 3.5Mio..nomicons/blink

"Le jour où tu découvres le Libre, tu sais que tu ne pourras jamais plus revenir en arrière..."

Re: QElectroTech version 0.5 Release Candidate 1 released

Merci Laurent pour toutes ces précisions qui font sens.
Je pensais que QET avait une fuite mémoire et je tenais à vous le signaler avant d'officialiser la release 0.5.
Vraisemblablement, ce n'est pas le cas, sinon les petites machines auraient déjà explosé nomicons/laughing

Re: QElectroTech version 0.5 Release Candidate 1 released

Merci Nuri de ton retour, déjà tu nous fais plaisir qu'en tu dis que tu as travaillé dessus 7 heures d'affilées, le code est maintenant bien plus solide qu'il a quelques mois en arrière.

Ce qui est normal, après les phases d'ajouts de nouvelles fonctions, il faut stabiliser tout ça, tout logiciel en passe par là.

J'arrive quand même à avoir un comportement bizarre et un crash, sans perte de données, heureusement pendant la sauvegarde avec tes symboles : câble brin haut/bas si je les supprimes : elles restent en partie affichées.

Juste remarqué ce problème dernièrement sur mes folios borniers, pas eut le temps d'investigué la dessus !

Les petites machines n'explosent pas hein, uhuhu, seulement travailler avec sur de gros projets faut être très patient.

Ça doit être le cas aussi avec ton Eplan, un Catia, Autocad, Solidworks sur une machine en Celeron avec 1Gio de RAM, tu dois pas travailler confortablement... c'est pas pour rien qu'ils vendent des workstations qui coûtent un rein.

https://download.qelectrotech.org/qet/f … tation.png

just waiting a happy donator nomicons/smile

"Le jour où tu découvres le Libre, tu sais que tu ne pourras jamais plus revenir en arrière..."

Re: QElectroTech version 0.5 Release Candidate 1 released

nuri wrote:

Je pensais que QET avait une fuite mémoire et je tenais à vous le signaler avant d'officialiser la release 0.5.

Je pense qu'on vas quand même faire une RC de plus, surtout parce que j'ai pas le temps, et surtout même pas commencé à préparer l’écriture de la dépêche là concernant. nomicons/sleeping
Par contre ce serait bien, si tu pouvais me filer un coup de main pour sa traduction en anglais et allemand si tu le souhaites.

"Le jour où tu découvres le Libre, tu sais que tu ne pourras jamais plus revenir en arrière..."