[gnucash-de] Gnucash auf Windows

[Christian Stimming]

Andreas Fromm schrieb:
> Das der Import von einer C funktion erledigt wird wusste ich nicht. Ich
> hab auch nichts gegen irgend welche Lisp dialekte. Ich hab mich zwar in
> der Praxis noch nie damit beschäftigt, aber wenn man ein so
> fantastisches Program wie Emacs darin schreiben kann, sind Lisp sprachen
> sicherlich nicht verkehrt. Ganz abgesehen von den sehr interesanten
> aspekten dieser Sprachen vom theoretischen standpunkt aus ...
> 
> Was mir nur aufällt ist, dass wärend ich HBCI transaktionen importiere
> ein guile-prozess ca 95% meiner CPU-time frisst. Daher der verdacht das
> der Import von diesem Prozess durchgeführt wird.

Kein Problem. Aber es gibt ja auch gar keinen Prozeß mit dem Namen 
"gnucash", denn das wird aus einem "guile"-Prozeß heraus aufgerufen.

Nichtsdestotrotz wäre ich auch extrem glücklich, wenn jemand diesen 
Code-Teil mal überprüfen würde, aber ich bin halt mit anderen Sachen 
beschäftigt.

Christian

> 
> Christian Stimming wrote:
> | Hallo Andreas,
> |
> | Andreas Fromm schrieb:
> |
> |> Besteht eigentlich die möglichkeit dann auch von dem guile-zueg
> |> wegzukommen? Das ist halt so ewig langsam und frisst enomre resourcen.
> |
> |
> | Hier werden zwei Fragen miteinander vermischt, die eigentlich gar nichts
> | miteinander zu tun haben. Tatsache ist, daß ein Teil von Gnucash in
> | Scheme/Guile geschrieben ist, und zwar ca. 10% vom Code. Tatsache ist
> | weiterhin, daß die Sprache Scheme (Lisp) nur relativ wenigen
> | Programmierern geläufig ist, und daß häufig das Wunsch auftaucht, ob man
> | nicht eine andere Scripting-Sprache benutzen könnte. Antwort dazu auf
> | http://gnomesupport.org/wiki/index.php/GnuCashCode
> |
> | Aber Scheme/Guile als solches ist weder langsam noch
> | ressourcen-fressend. Das eine hat mit dem anderen nichts zu tun.
> |
> |> Ich kenne mich mit den interna von GnuCash zwar überhaupt nicht aus,
> |> aber ich kann mir nicht vorstellen dass es so wahnsinnig rechenaufwendig
> |> ist, z.B. die Umstazdaten die per HBCI abgeholt werden in die Konten
> |> einzupflegen. Das dauert auf meinem Rechner (P3,600MHz) zum Teil über
> |> eine Minute für ca 30-40 Überweisungen.
> |
> |
> | Wenn Deine Anfrage sich auf das spezifische Problem "Import von
> | Umsatzdaten" bezieht und das Problem lautet, daß dieser Import sehr
> | langsam geschieht, dann stimme ich zu, daß dies der Fall ist. Aber der
> | Grund für dieses langsame Importieren hat einzig und allein mit einer
> | "relativ langsamen Implementierung" [1] der Import-Funktion zu tun, und
> | diese wiederum ist in den C-Dateien
> | src/import-export/import-main-matcher.c (gnc_gen_trans_list_add_trans()
> | übergibt die "halb-fertigen" Transactions vom HBCI-Plugin an den
> | endgültigen Importer) , src/import-export/import-match-map.c und
> | src/import-export/import-backend.c zu finden. Die Performance-Probleme
> | beim Import werden behoben sein, *sobald* sich jemand mit diesen drei
> | Dateien hinsetzt und herausfindet, wo dort die viele Zeit verschwendet
> | wird. (Hinweis: Wenn jemand weitere Code-Dokumentation sucht, sollte man
> | *immer* den HEAD-branch vom CVS verwenden, da dort inzwischen viel mehr
> | doxygen-Kommentare eingefügt worden sind.)
> |
> | Ich wiederhole nochmal: Das hat mit Scheme/Guile überhaupt nichts zu tun.
> |
> | Christian
> |
> | [1] Jeder Programmierer möge sich die tiefere Bedeutung dieser
> | Charakterisierung selber ausdenken.
> 
> - --
> Grüße,
> 
> Andreas Fromm
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.6 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
> 
> iD8DBQFBpI0bUmBtSMq5cGURAvWmAKC9Wel/y6qrN7UXjNVnSeTNiokgrgCgiHam
> KeuHBOsv04kVAD1bZd+aKvU=
> =Jpqx
> -----END PGP SIGNATURE-----
>