Comparing KHTML in Quanta and Konq

[Carsten Pfeiffer]

-----BEGIN PGP SIGNED MESSAGE-----

On Wednesday 28 May 2003 15:20, Maksim Orlovich wrote:

> I also recall doing dcop broadcasts to update history taking nearly 12ms
> per process or so (if you recall the change to prevent broadcasts of
> about:konqueror updates that I suggested to speed up the startup);
> perhaps getting only a single kded module as a destination and making
> it lazily (or pull?) propagate it could help the performance, too,
> but that's getting tricky & needs measurements.

I don't think pulling the history on demand from somewhere (a kded module or 
whatever) is feasible, because you don't know when you need to pull. Surely, 
e.g. during url-completion you know that you need an up-to-date completion 
(and hence history). But what about e.g. the history view in the sidebar? It 
needs to get updated as soon as the history changes.

Supporting both push and pull would add a lot of complexity for little gain, 
I'm afraid.

I'm wondering where those 12ms are spent. The only slow thing in 
KonqHistoryManager is the O(n) traversal of the list to find a history entry. 
This could be sped up by additionally indexing the entries by their url at 
the expense of increased memory usage.

Cheers
Carsten Pfeiffer
-----BEGIN PGP SIGNATURE-----

iQEVAwUBPtTva6WgYMJuwmZtAQHcXggAhHrmyAwelsRSKv6BveMq2cPcp0OhkYRd
RlEZTIodlyTw5zUV7WT+OqeonEtYpqDSBUorBKtnjuLlEtUCYXp1EL2ZGcDgAKLR
14gXUHu8TccgCZZzYWjqdwKTJICoTwizFdyZNfSCKWriYLvCWWKqX3LW7XxUQINI
OTlUcNs6maa1KaNqog0vARCWLzupd3HdqyEovVHJ7fDkRjCikoDKN9symnLOlhEB
1X5Ak0EoFaZb3wjibnbnqbHS+57jSDV0FxVXO4BVjWCLRwv83ZjQkgel8Zl3v2mR
Pb2IO8msrC+qga6nAEhWRiQxsWrdlRH8NJSEhXhvE3e5Cyb0PFXINA==
=2A4D
-----END PGP SIGNATURE-----