2009-11-12 5 views
1

Nous avons une application de surveillance construite sur swt et fonctionnant sous Linux. nous avons quelques boutons et une partie dynamique qui change lorsque nous cliquons sur ces boutons. Le problème est que si certains cliquent trop rapidement, le processeur peut atteindre 100% et être suspendu pour toujours. Nous avons observé ces pics rapides de cpu seulement sur Ubuntu Linux où en tant que fenêtres il fonctionne sans démangeaisons. Nous sommes sûrs que notre application repeint chaque fois que nous cliquons (nous avons une partie dynamique) sur le bouton et c'est par conception. Le problème n'est pas seul avec la partie dynamique. Une solution consiste à ignorer les clics rapides.problème de performance swt GUI sur linux

Nous nous demandons si nous pouvons ignorer les clics rapides des boutons pour éviter que le cpu n'atteigne 100%. Si cela ne fonctionne pas, nous devrons peut-être revoir la partie dynamique que nous préférons comme dernière option. Les suggestions/commentaires sont grandement appréciés.

Répondre

0

Une autre solution est d'augmenter votre mémoire avec -Xms512m -Xmx512m

+0

Avec plus d'enquête, j'ai trouvé que ma boîte Linux est à court de mémoire et je ne vois rien dans les journaux. Ma mémoire de tas est dans les limites. Donc maintenant je soupçonne qu'il pourrait y avoir une fuite de mémoire natif puisque nous utilisons swt. Quand j'ai regardé le code, une classe utilise la méthode finalize pour disposer l'objet swt. Je soupçonne que ça pourrait être le coupable. Est-ce que cet objet est finalisé par gc mais laisse les ressources mémoire natives et provoque des fuites? – Kishore

+0

pourrait être ... finaliser est indéterministe. Vous ne devez pas utiliser finaliser pour libérer la mémoire dans SWT. – nanda

+0

Oui. Nous avons du code pour libérer la mémoire native dans les méthodes de finalisation.Bien que nous ne l'ayons pas ré-factorisé, nous avons prévu de le faire. – Kishore

0

Il semble que l'application soit simplement dans une impasse. Utilisez-vous des threads?

Vérifiez si la repeinte est effectivement la cause de l'application suspendue. Vérifiez également quel fil il utilise:

Thread.currentThread() 

Si c'est le thread principal, alors quelque chose est intrinsèquement faux; cela pourrait être un problème dans Java même. S'il s'agit d'un thread, assurez-vous qu'il n'attend pas la fin de la synchronisation d'un autre thread.

+0

Merci. J'ai utilisé Jconsole pour surveiller l'application et pour détecter les blocages et je ne vois aucun d'entre eux dans l'impasse. – Kishore

0

J'ai le même problème sous Ubuntu. Mais sur OpenSuse, ça semble beaucoup mieux.

Les choses que vous pouvez essayer:

Définir l'alias et anti option avancée de la GC, comme:

gc.setAntialias(SWT.OFF); 
gc.setTextAntialias(SWT.OFF); 
gc.setAdvanced(false); 

et vérifiez si vous utilisez le pilote graphique commercial (par exemple de NVIDIA ou ATI) et pas le pilote open source.

0

Try this ou utiliser pstack ou lsstack. Lorsque l'application fonctionne longtemps (ou se bloque), c'est quand il vous supplie de jeter un coup d'œil et de voir ce qu'il fait.

0

De nombreuses personnes ont rencontré des problèmes de performance (c'est-à-dire une consommation d'UC très élevée) avec des applications SWT sur Gtk + lors de la mise à jour de widgets trop souvent. La cause réelle semble être Gtk +.

Bien qu'un peu obsolète, here est une explication complète de ces problèmes de performance.

Vous pouvez essayer de remplacer vos composants SWT par embedded Swing et de vérifier si les problèmes sont toujours reproductibles.