> Are wireshark's developers interested in reviewing and committing these patches?
reviewing ,yes certainly . Committing, depends I suspect :-)
>-1 Base on Yami's work "snapshot feature: apply filter upon previous displayed packets only" (without the SAT, only using a true table). help a lot when >users are building filters incrementally or move a lot between them.
>2 When filtering don't dissect packet if not necessary. Help a lot, can speed filtering up to 2 orders of magnitude (twice to three time as fast common).
Could you give a brief description on how it works or is it simpler to just submit a patch? Seems like a waste to do a patch and having it rejected for some reason. I have some ideas on 1 and 2 too and it would be interesting to see if they are similar.
Reagrds
Anders
-----Original Message-----
From: wireshark-dev-bounces@xxxxxxxxxxxxx [mailto:wireshark-dev-bounces@xxxxxxxxxxxxx] On Behalf Of - Aucun -
Sent: den 31 oktober 2013 12:03
To: wireshark-dev@xxxxxxxxxxxxx
Subject: [Wireshark-dev] speed optimizations
Hi,
Years ago for our internal use I made a lot of speed related changes to wireshark (then ethereal).
Some of these changes are currently in wireshark but many aren't.
Lately I'm looking at qt work and I'd like to move our internal tool to it.
A simple merge is DOA, vs our wireshark version the diff is a 100MB patch :(, thus it's simpler to more or less rewrite them, they aren't that big, and it's the right time to try to move them in wireshark code.
Of course a proper patch ready for commit in wireshark tree is more work than a quick and dirty one good enough for only our usage.
Are wireshark's developers interested in reviewing and committing these patches?
There's roughly four set of patches.
-1 Base on Yami's work "snapshot feature: apply filter upon previous displayed packets only" (without the SAT, only using a true table). help a lot when users are building filters incrementally or move a lot between them.
-2 When filtering don't dissect packet if not necessary. Help a lot, can speed filtering up to 2 orders of magnitude (twice to three time as fast common).
-3 a lot of small ones which only make sense once 2 is in, for example when you're filtering at 300 000 packets/sec, one lseek/read per packet hurt.
-4 rewrite packet dissectors, AOT and JIT(*), we are using an internal tool I can't share (too buggy) but it could be done with either LLVM or ugly preprocessing at compile time for AOT.
I'm willing to work on pushing 1,2,3 in wireshark.
It's more complicate for 4 as it's working for us (ie I don't have a budget for a big rewrite using LLVM).
Any takers?
Regards
Didier
___________________________________________________________________________
Sent via: Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives: http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe
