CPU hogging in the current master

[Linus Torvalds]

On Thu, Sep 26, 2013 at 9:23 AM, Dirk Hohndel <dirk at hohndel.org> wrote:
>
> Now after our conversation outside of Starbucks at The Gardens Mall in
> West Palm Beach I created an artificial dive file with 5000 dives. Now
> that is BAD even on my fast laptop. So that is an area where I think
> optimizations would be more useful - and if we were to change data file
> formats, I'd like to do this together with the major version switch if
> at all possible.
>
> Have you looked into that?

So I thought about it a bit. My main problem was that I couldn't come
up with a really nice-looking format that was worth the pain.

Can you send me the fake dive file, just so I don't have to fake my own?

I do have a trivial patch to speed up xml matching, because I decided
to try that one again. It's appended (the "-q" flag is to help time
startup, it's not important otherwise, but we had something like that
in the gtk version for similar reasons).

The attached patch speeds up xml matching by creating the nodename the
other way around (innermost entry first), which makes the diff
painfully large, but 99% of that is just basically mindlessly fixing
the comparison strings to match the new rule. Doing the name
"little-endian" then makes it possible to skip the "len" argument and
simplify the name comparisons, in particular exiting early for length
mismatches.

The stupid xml parsing is still quite noticeable, but on my normal
file it's now actyally less so than both dynamic linker startup costs
(which are quite noticeable for the Qt build - more so than for gtk,
iirc) and the tissue tolerance calculations for the first set of
dives.

Of course, the problem with the xml file is that the cost scales with
size of file. But I might be able to bring it down some more.

                  Linus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch.diff
Type: application/octet-stream
Size: 22726 bytes
Desc: not available
URL: <http://lists.hohndel.org/pipermail/subsurface/attachments/20130926/587f9686/attachment-0001.obj>