Hi,<br><br>> You could save the time needed to load python and especially to load<br>> the python modules.<br>Python caches them very well. It won't take any relevant amount of time when loading modules for the second time (you can easily try that out in a terminal). :)<br>
<br>I'll have a look at the DUChain ItemRepository thingy, thanks for the hint.<br>But I cannot imagine why using SQLite should be so difficult or "fat"... it's part of most Qt distributions, isn't it? At least for me, it was available automatically.<br>
And I imagined loading and storing things would be like... 2 lines, where do you see a possibility for thousands of lines of code there? If the file ever gets corrupted (which I don't expect to happen, will it?) I can easily just delete it. It's just a cache.<br>
Plus, a "real" (sorry :) database would be way more flexible in terms of searching, distributing with predefined data, exporting/importing, ...<br><br>But i'll definitely have a look at the DUChain method.<br>
<br>Thanks,<br>Sven<br><br><div class="gmail_quote">2010/11/17 David Nolden <span dir="ltr"><<a href="mailto:zwabel@googlemail.com">zwabel@googlemail.com</a>></span><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
2010/11/17 Sven Brauch <<a href="mailto:svenbrauch@googlemail.com">svenbrauch@googlemail.com</a>>:<br>
<div class="im">> Hi!<br>
><br>
> Thank you very much for your answers.<br>
><br>
> Well David, it's not only about speed; I also consider it extremely<br>
> inelegant to waste CPU time for virtually nothing. There's really no reason<br>
> to generate documentation for a module 20.000 times a day when there's no<br>
> chance it'll ever change... plus, progress indicators are very nice, but<br>
> being fast enough to leave them out is always nicer. :) Also, for some<br>
> modules like QtGui, it takes about 30 seconds to generate documentation; of<br>
> course, you don't want to show all that in a tooltip, but maybe the<br>
> sub-packages listed there, and being able to load those from a databse is<br>
> much nicer than yet another pydoc hack. But I agree, waiting for 0.5 seconds<br>
<br>
</div>Well, how do you fill the database? It will also require a kind of<br>
pydoc, so the question is just: Is it better to add 50 lines of code<br>
in the pydoc plugin, or is it better to add a thousand of lines of<br>
code to KDevelop, plus an additional "fat" dependency, which is<br>
SQLite.<br>
<br>
With the database, you will have the typical load of work like always<br>
with databases. Where to store it? What about multiple running<br>
instances? Is the database corrupted? Is the entry you're requesting<br>
still current? And then bugs, bugs bugs. I have experience with this<br>
because we used a separate database in KDevelop3 for the code model.<br>
<br>
We already maintain a database, which is the duchain storage, so if<br>
you consider a database as a cache, then it should be that one. It is<br>
much more efficient than any SQL database, and already has perfect<br>
integration with KDevelop, so you won't have to worry about any of the<br>
points above (except for the "Is the entry still current"). You can<br>
easily use a duchain ItemRepository as a database, as is done in many<br>
components. Take a look at kdevplatform/language/duchain/uses.h /<br>
uses.cpp, there you have a fully working simple single-key database.<br>
You just have to copy it over, change the names, and change the data<br>
types. For example, you could map from IndexedQualifiedIdentifier to<br>
any set of Indexed.... types you add to the "UsesItem" successor, plus<br>
a dynamic list of the item type you add through the APPENDED_LIST_...<br>
stuff.<br>
<div class="im"><br>
> I considered keeping the python scripts running for the parser, too, but I<br>
> dismissed it because it's simply not worth it. The only thing you could save<br>
> with that is time needed for startup; which is actually only needed once<br>
> because python caches stuff very well (and also keeps semi-compiled versions<br>
> of the script around, so it's not even reparsed).<br>
<br>
</div>You could save the time needed to load python and especially to load<br>
the python modules. I don't know where most of the time is wasted<br>
though, so maybe this wouldn't help much.<br>
<div><div></div><div class="h5"><br>
Greetings, David<br>
<br>
--<br>
KDevelop-devel mailing list<br>
<a href="mailto:KDevelop-devel@kdevelop.org">KDevelop-devel@kdevelop.org</a><br>
<a href="https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel" target="_blank">https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel</a><br>
</div></div></blockquote></div><br>