Search options (Page 242 of 300)

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.

Merci du retour, pas mal de nettoyage de code et autres améliorations ont été effectués depuis la RC1, pas spécifiquement sur l’éditeur et ton problème, mais ça vaut toujours le coup de tester avec les derniers builds.

Il me semble qu'a une époque, j'avais eu ce style de désagrément avec des symboles dessinés sous Windows au boulot, et parfois décalés une fois lu sur ma Debian en rentrant !

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

Je vous faits grâce des acces disques 

video

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.

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.

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!

Je te dirai bien dans l'onglet conf de régler le "save path" vers le chemin de ta collection personnelle, mais les elmt fraîchement convertis ne sont pas encore prêt à être placés directement dans les folios.
Il faut les ouvrir avec l’éditeur : l’éditeur ajoutera automatiquement la bonne valeur au hotspot à la sauvegarde!

Heuuu... vas plutôt dans l'onglet config !

i just uploaded your elements in common collection.
Send me your updated Guitar elements to sync to common collection.

Is Qt5 Archlinux packages, or upstream tarball and build by yourself?

Updated new builds  to :
Revision: 4262
Author:   rdsivd
Date:     2015-11-15 13:14:00 +0100 (Sun, 15 Nov 2015)
Log Message:
-----------
DXFtoQET update text conversions for acad blocks

At the moment, i build with Qt 5.3.2 for Debian Jessie, Qt 5.5.1 for Debian Sid and Windows packages.