Eclipse CDT (4.5.1) fonctionne lentement avec une jolie impression

Question

J'ai un problème avec d'énormes structures de données imbriquées (à partir de JSON Spirit). Lors du débogage, lorsque cette structure est remplie de données, Eclipse commence à fonctionner très lentement, après chaque étape d'attente de données imprimées de GDB. Le fait est que Eclipse rassemble beaucoup d'informations sur les variables locales même si je n'élargis pas cette structure de données. Quand la jolie impression est désactivée, cela fonctionne, mais bien sûr, je ne vois rien à l'intérieur des conteneurs STL.

J'utilise les imprimantes de GDB SVN

Voici un petit morceau de code qui peut faire des problèmes similaires:

#include <iostream> 
#include <string> 
#include <map> 

int main() { 
    std::map<std::string, std::map<std::string, std::map<std::string, std::string>>> mega_map; 

    const int factor = 50; 
    for (int c = 0; c < factor; ++c){ 
     std::map<std::string, std::map<std::string, std::string>> b_map; 
     for (int b = 0; b < factor; ++b){ 
      std::map<std::string, std::string> a_map; 
      for (int a = 0; a < factor; ++a){ 
       std::string a_str = "a"; 
       a_str += (std::to_string(a)); 
       auto a_pair = std::make_pair("aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" + a_str, "zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz"); 
       a_map.insert(a_pair); 
      } 
      std::string b_str = "bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb"; 
      b_str += (std::to_string(b)); 
      b_map[b_str] = a_map; 
     } 
     std::string c_str = "cccccccccccccccccccccccccccccccccccccccc"; 
     c_str += (std::to_string(c)); 
     mega_map[c_str] = b_map; 
    } 
    return 0; 
} 

Il suffit de faire un frein à « retour », et vous verrez qu'il faut beaucoup de temps pour obtenir quelque chose dans la fenêtre 'Variables'. Pendant ce temps, vous ne pouvez pas déboguer.

Il existe un indicateur dans GDB set print elements number-of-elements qui peut limiter le nombre d'éléments dans les conteneurs à imprimer, cela fonctionne mais si ces structures imbriquées ne m'intéressent pas, ces paramètres affectent d'autres conteneurs que je voudrais inspecter.

Des idées pour y remédier?

Merci.

Answer 1

Nous (collègues et moi-même) avons fait une enquête sur ce problème aujourd'hui, et voici notre conclusion. Malheureusement, nous n'avons pas trouvé le moyen de résoudre ce problème en utilisant uniquement certains paramètres, mais nous avons trouvé des changements dans CDT et GDB qui pourraient aider à l'atténuer. Si vous pouvez créer votre propre CDT ou GDB, cela peut vous aider.

CDT demande à GDB pour les variables locales utilisant -stack-list-locals, avec l'argument pour obtenir leurs valeurs également. Pour un joli récipient imprimé, GDB finit notamment les enfants:

std::vector of length 20, capacity 20 = {<children here>} 

Pour les structures de données imbriquées, il peut finir énorme. Une solution consiste à faire en sorte que CDT ne demande pas ces valeurs. Il utilisera correctement les objets variables et demandera les valeurs nécessaires au fur et à mesure que vous développez les structures de données. Voici la diff:

diff --git a/dsf-gdb/org.eclipse.cdt.dsf.gdb/src/org/eclipse/cdt/dsf/mi/service/MIStack.java b/dsf-gdb/org.eclipse.cdt.dsf.gdb/src/org/eclipse/cdt/dsf/mi/service/MIStack.java 
index c319eb8..23bbb8a 100644 
--- a/dsf-gdb/org.eclipse.cdt.dsf.gdb/src/org/eclipse/cdt/dsf/mi/service/MIStack.java 
+++ b/dsf-gdb/org.eclipse.cdt.dsf.gdb/src/org/eclipse/cdt/dsf/mi/service/MIStack.java 
@@ -859,7 +859,7 @@ implements IStack, ICachingService { 
      fMICommandCache.execute(
        // Don't ask for value when we are visualizing trace data, since some 
        // data will not be there, and the command will fail 
-     fCommandFactory.createMIStackListLocals(frameDmc, !fTraceVisualization), 
+     fCommandFactory.createMIStackListLocals(frameDmc, false), 
        new DataRequestMonitor<MIStackListLocalsInfo>(getExecutor(), rm) { 
         @Override 
         protected void handleSuccess() { 
@@ -988,7 +988,7 @@ implements IStack, ICachingService { 
       // the result without the values 
       // Don't ask for value when we are visualizing trace data, since some 
       // data will not be there, and the command will fail 
-    fCommandFactory.createMIStackListLocals(frameDmc, !fTraceVisualization), 
+    fCommandFactory.createMIStackListLocals(frameDmc, false), 
       new DataRequestMonitor<MIStackListLocalsInfo>(getExecutor(), countingRm) { 
        @Override 
        protected void handleSuccess() { 

Il y a d'autres cas où CDT émettra des demandes qui GDB crachez la structure de données récursive complète, qui est si vous avez vue la variable sélectionnée dans les variables ou si vous passez la souris elle. Ensuite, vous remarquerez la valeur étendue complète dans la section "Détails". Mais si vous n'avez pas cette variable sélectionnée au fur et à mesure que vous progressez, elle réagit rapidement.

La solution possible dans GDB est de ne pas générer de jolies structures de données imprimées récursivement. Ce hack par exemple les limite à un niveau des enfants:

diff --git a/gdb/python/py-prettyprint.c b/gdb/python/py-prettyprint.c 
index 66929bf..b213699 100644 
--- a/gdb/python/py-prettyprint.c 
+++ b/gdb/python/py-prettyprint.c 
@@ -700,7 +700,7 @@ gdbpy_apply_val_pretty_printer (const struct extension_language_defn *extlang, 
    /* Print the section */ 
    print_result = print_string_repr (printer.get(), hint.get(), stream, 
        recurse, options, language, gdbarch); 
- if (print_result != string_repr_error) 
+ if (print_result != string_repr_error && recurse == 0) 
    print_children (printer.get(), hint.get(), stream, recurse, options, 
      language, print_result == string_repr_none); 

A pourrait être considérée comme contribution à l'amont GDB où cette limite de récursion est un paramètre avec une valeur raisonnable.