| | <<<Back 1 day (to 2014/12/28) | 20141229 |
| Robin_Watts | Odd. mujstest builds seem broken for me. | 15:42.06 |
| malc_ | Robin_Watts: few data points | 18:13.44 |
| | Robin_Watts: the speed after your commit has decreaseed ten fold | 18:14.08 |
| | Robin_Watts: there's a simple thing that can be done to improve it 2x, but where to get the rest 5x i don't know | 18:14.56 |
| | and also i was wrong about ppc not suffering for it (was building it there (on a ppc) against different mupdf checkout) | 18:15.48 |
| Robin_Watts | malc_: Right, that's good to know. | 18:16.02 |
| | I head out on holiday tomorrow for a few days - I will try to have a look in the evenings while I am there. | 18:16.36 |
| malc_ | Robin_Watts: just printing xref table should tell you something, it's rather nasty i believe | 18:16.54 |
| Robin_Watts | malc_: For the ARMARMv8 file? | 18:17.07 |
| malc_ | Robin_Watts: aye | 18:17.13 |
| Robin_Watts | One possibly way to improve it would be to always flatten the topmost xref. | 18:17.30 |
| malc_ | mucleaning it does wonders though | 18:17.33 |
| Robin_Watts | yeah. | 18:17.39 |
| malc_ | at the expense of making the file 2x larger or so | 18:17.48 |
| Robin_Watts | the problem is that flattening the topmost xref ruins our ability to do incremental updates. | 18:18.31 |
| | Possibly we can solve that though by altering our usage so that topmost one is a 'cache'. | 18:19.02 |
| | I need to have a think about it. | 18:19.06 |
| malc_ | and the thing that improves things 2x is just returning the xref from pdf_cache_object (given that the code that calls that immediately goes into find xref) | 18:20.15 |
| Robin_Watts | malc_: OK, I'll keep that in mind, thanks. | 18:21.15 |
| malc_ | Robin_Watts: http://pastebin.com/raw.php?i=n3vpauVP | 18:39.57 |
| | Robin_Watts: also at line 233 in pdf-xref.c there's a superfluous test for i >= 0 (the function throws if it aint so before) | 18:41.37 |
| Robin_Watts | Any Artifex devs here? (other than me :) ) | 18:51.03 |
| henrys | Robin_Watts: I've been in and out today... probably should have declared it vacation. | 19:31.53 |
| Robin_Watts | henrys: Could you nod at some reviews please? | 19:33.00 |
| | http://git.ghostscript.com/?p=user/robin/mupdf.git;a=commitdiff;h=7209f8811b61007f999afcb78d4440a805d853f4 | 19:33.04 |
| | http://git.ghostscript.com/?p=user/robin/mupdf.git;a=commitdiff;h=319c9d2315ad4fb13abe423571311ddb63202e2c | 19:34.08 |
| | http://git.ghostscript.com/?p=user/robin/mupdf.git;a=commitdiff;h=15d7a79f92e3799d3db0b2b1c733635701da04d9 | 19:34.17 |
| henrys | okay 1st one is trivial fine with that. | 19:35.21 |
| Robin_Watts | (all have passed the cluster test) | 19:35.42 |
| henrys | Robin_Watts: I'm good | 19:39.08 |
| Robin_Watts | Thanks. | 19:39.13 |
| | malc_: Ok, so my current idea for getting the speed back... | 19:41.59 |
| | We allocate a block of ints, 1 per object. | 19:42.16 |
| | We init them all to be -1. | 19:42.30 |
| | The we make block[objnum] = the xref in which object objnum is in (or -1 for not present anywhere) | 19:43.22 |
| | That way when we do pdf_xref_get_object we do 1 lookup to find the xref number. No searching required. | 19:44.00 |
| malc_ | Robin_Watts: might work, as my other experiment with just returning previous entry if asked repeatedly for the same object resulted in ~9x speedup | 19:44.45 |
| Robin_Watts | A simple one place cache gives us a 9x speedup? | 19:45.28 |
| | Is that on top of the 2x speedup you found earlier ? | 19:45.41 |
| malc_ | Robin_Watts: that's _without_ the 2x | 19:45.56 |
| | for ARMv8 it does wonders | 19:46.10 |
| Robin_Watts | So with the both fixes in, are we faster than before? | 19:46.14 |
| malc_ | nope | 19:46.19 |
| Robin_Watts | how much slower than before? | 19:46.44 |
| malc_ | Robin_Watts: have you tried the speed.c test that i mentioned? | 19:46.46 |
| Robin_Watts | malc_: No, I've been fixing SEGVs etc. Only just started to think about this. | 19:47.06 |
| | malc_: Where was the speed.c test please? | 19:47.42 |
| | (Sorry, this is why doing stuff in public is best as it's logged) | 19:47.58 |
| malc_ | Robin_Watts: http://boblycat.org/~malc/speed.c | 19:48.52 |
| | fix the path to the pdf and you are good | 19:49.05 |
| Robin_Watts | malc: I've just pushed 3 commits. | 19:49.34 |
| malc_ | Robin_Watts: thanks | 19:49.45 |
| Robin_Watts | 1 is a modified version of your pdf_cache_object/pdf_get_xref_entry thing. | 19:50.04 |
| malc_ | Robin_Watts: it's not gcc code though, it's C99 :) | 19:50.11 |
| Robin_Watts | 1 is the removal of the i >= 0 check. | 19:50.15 |
| | malc_: C99 does not allow variables to be defined not at the top of the block, AIUI. | 19:50.39 |
| malc_ | Robin_Watts: it does | 19:50.47 |
| Robin_Watts | malc_: Hmm. fair enough. | 19:51.38 |
| | I'm going to run the object index idea past tor/paul to see what they think. | 19:52.39 |
| | I need to figure out if the 1 place cache idea has problems with multithreading. | 19:53.01 |
| | I fear it will, which would require extra locking, and that would be bad. | 19:53.22 |
| malc_ | indeed | 19:53.35 |
| Robin_Watts | foods. | 19:53.58 |
| malc_ | Robin_Watts: still here? | 20:58.59 |
| | Robin_Watts: http://pastebin.com/raw.php?i=iAsq2rWB with this things are back to pre xref reorg speed | 21:23.36 |
| Robin_Watts | malc_: Ah, cool. | 21:36.06 |
| | I'll try and get that applied some time soon. | 21:36.16 |
| malc_ | thanks | 21:36.22 |
| Robin_Watts | but not right now :) | 21:36.27 |
| malc_ | 00:35 here, i can probably sleep it over ;) | 21:36.48 |
| | Forward 1 day (to 2014/12/30)>>> | |
IRC Logs