Small (un-representative) benchmark on sqlite with blobs

[Roberto Raggi]

Hi!

Il giorno 25/giu/07, alle ore 12:43, Andreas Pakulat ha scritto:

> On 25.06.07 10:49:37, Roberto Raggi wrote:
>
> Nobody said we're going to store the data in a relational schema.  
> David
> mentioned something like 2 Map-like tables. So the SQL-statements are
> surely no problem. The real data will be stored as Blob, which is the
> whole reason I did this experiment.

interesting.. so why SQL? you can pretty much use everything else for  
that.

>
>> KDevelop is not a compiler, you don't need to
>> store a lot of information in its persistent storage. I think you can
>> use an approach similar to the per project PCS file I did for
>> KDevelop 3. The project's PCS file is a dump of the Code Model,
>
> a) there's no code-model
I was talking about kdev3's PCS file ;-)

> b) AFAIK, the duchain is global for all projects, to allow to lookup
> symbols from other projects and save space and time when projects use
> common headers (like a handful of Qt projects). (Kris or David know  
> this
> exactly)
hmm, I'm confused. I think we are talking about different things ;-)  
A DU chain is a Definition-Use chain. That means if you have a  
definition (e.g. the method setObjectName of QObject) you can ask for  
the uses of that definition in the current translation unit. As you  
can see this thing is very dynamic. For example, if at some point you  
call the method setObjectName() from the function whatver() of your  
project you will change the DU chain, and that's OK, but as you can  
see this is just a chain of a definition and a use, and you need to  
define what is a use and what is a definition (== you need some sort  
of model). Then you need to know where the definition is created (==  
scope), and so on.. Maybe the DU chain in KDevelop 4 is a "super DU  
chain" that is a mixture of scopes, symbol tables, environments, & co.

ciao robe