Ph. Marek
changed
bug 9943
| What |
Removed |
Added |
| CC |
|
philipp+wireshark@marek.priv.at
|
Comment # 1
on bug 9943
from Ph. Marek
Some other simple optimizations might be useful.
*) determine which fields are strictly ordered - eg. frame.number comes to
mind. A filter (subclause) having "frame.number <= 100" can quit looking at
frame number 101, for example.
*) Similar reasoning for other fields is possible. Eg. the timestamp _should_
be (mostly) increasing; at loading the file the "fuzziness" could be determined
(ie. how many packets apart the time stamp order is violated), and then
filtering might be stopped early again.
These ideas sound very much like the things databases did for some time ...
How about an option to load the parsed fields into some DB (sqlite [because
it's in-process], PostgreSQL [because the query optimizer is very good]), and
then retrieve the frame numbers via an SQL query?
(I'm aware that a DB scheme might not be that easy here. Although, with recent
PostgreSQL JSON improvements, how about "simply" importing the packet data as
JSON (via PDML and XML2JSON?) and let Postgres figure out the rest??
There's a 9.4beta1 in the debian experimental repository...)
(Alternatively, to avoid the external dependency, perhaps the sqlite query
planner could be reused in wireshark ... TBH, I'd be more interested in the
PostgreSQL solution ;)
You are receiving this mail because:
- You are watching all bug changes.
