| | <<<Back 1 day (to 2014/04/17) | 2014/04/18 |
| ray_laptop | the improvements to the PDF parser result in a 30% parse time improvement on my laptop with HEAD. Starting a regression run ! | 00:16.43 |
| | Note that is with this particular type of file with lots of text. I'll test the PLRM as well. | 00:17.28 |
| | chrisl_away: (for the logs, also sent email) the simulator code (with ALL of my mods) is on casper.ghostscript.com:alp2_venus_2014_04_17.zip | 00:18.36 |
| | chrisl_away: (for the logs, also sent email) the simulator code (with ALL of my mods) is on casper.ghostscript.com:/home/ray/alp2_venus_2014_04_17.zip | 00:19.01 |
| | the PRLM only improves by 10% -- but it's better than nothing :-) | 00:27.03 |
| | running a regression test on the change now | 00:36.01 |
| | oops -- ppmraww is NOT a good filter :-( | 00:37.39 |
| | mvrhel_laptop: so you are still doing gs bugs ? You must be *really* fed up with fighting viewer problems ;-) | 00:42.23 |
| mvrhel_laptop | hi ray_laptop | 00:42.40 |
| | no a free user pinged me and said that robin sent him | 00:42.55 |
| | and I was being a nice guy and said I *might* look at it by next week | 00:43.18 |
| | I am getting close to having this text selection stuff finally working | 00:43.31 |
| ray_laptop | I heard (on the phone) that Len said that or (kens and mine) PDF interpreter change gets us really close to the target time | 00:43.55 |
| mvrhel_laptop | then I just have a few things to add with respect to using the stuff from mutool | 00:43.58 |
| | ray_laptop: that is great! | 00:44.11 |
| | I am going to try to get some sleep tonight. this damn thing has kept me up late each night and then I still have to get up early to help get kids out the door | 00:45.23 |
| | ok. the text selection is now all working | 00:50.26 |
| | need to clean up a couple minor things | 00:50.43 |
| ray_laptop | darn. Regression test turned up some diffs (and bmpcmp shows they are wrong). I don't understand how they can happen, but I didn't really look at what PreserveTrMode does :--/ | 01:02.12 |
| | oh, great. The PreserveTrMode toggles around with some of the files :-( | 01:09.56 |
| | now to find out why it does that... | 01:11.00 |
| | well, the speedup is good enough. So what if there are a few missing characters ;-) | 01:31.16 |
| mvrhel_laptop | ok. text selection stuff is pushed. now on to adding the stuff in that mutool provides, then I think I will be done... | 03:56.47 |
| | except for clean up and making the installer and I will need some QA from everyone | 03:57.23 |
| kens | Ray, if the value of PreserveTrMode is changing during the course of the job then as far as I cna see this must be caused by the device changing (as I suggested last night). The only devices which implement this paramter are txtwrite, pdfwrite and ps2write, txtwrite and pdfwrite have the value hard-coded to true, ps2wtite to false. | 07:20.14 |
| | If a device doesn't support the parameter, then its false. I would guess that during the course of the job we are isntalling another device (eg to flatten to an image) and that device, quite correctly, doesn't support preserving the text rendering mode. | 07:21.12 |
| spanners | Robin_Watts: You'd best email your font query as I'm busy with the (ill) kids. | 10:05.02 |
| Robin_Watts | spanners: Sorted, I think. | 10:12.00 |
| | but thanks! | 10:12.04 |
| mikkado | Hello, is git://git.ghostscript.com/ghostpdl.git/ is valid URL for repository? | 10:59.36 |
| | fatal: unable to connect to git.ghostscript.com: | 11:01.54 |
| chrisl | mikkado: you would probably be better use http protocol, rather than git protocol | 11:03.11 |
| | mikkado: having said that, try again now? | 11:04.17 |
| mikkado | I'll try it right now! | 11:06.29 |
| | Flying tortoises... | 11:07.48 |
| | Cannot obtain needed tree 38be4c201d89270a914d9740e631a8748269400a | 11:52.12 |
| | while processing commit 821d4c00e4507c0f68fd1eafb00622cbabcd1343. | 11:52.16 |
| | error: Fetch failed. | 11:52.22 |
| | =( | 11:52.25 |
| | Could not load sources | 11:52.31 |
| | =( | 11:52.32 |
| | Cloning into 'C:\Users\zadorozhnyj\Desktop\Ghost\ghostpdl'... | 11:52.50 |
| chrisl | <shrug> it worked for me | 11:54.40 |
| Robin_Watts | mikkado: git --version ? | 11:55.33 |
| mikkado | git version 1.8.3 | 11:56.03 |
| Robin_Watts | You're using wingit? The GUI front end ? | 11:56.21 |
| mikkado | TortoiseGit 1.8.4.0 | 11:56.32 |
| Robin_Watts | So you should have an msys git setup with that too, right? | 11:57.27 |
| mikkado | hm | 11:57.48 |
| chrisl | I thought TortoiseGit was standalone? | 11:58.25 |
| mikkado | It install all what I need to use with git | 11:58.52 |
| | I don't know how it is realy works =) | 11:59.20 |
| chrisl | Oh, no it seems it doesn need msys git | 11:59.28 |
| Robin_Watts | mikkado: Do you have a command line window where you can execute git commands? | 12:00.22 |
| mikkado | I can execute, but I never use it. | 12:00.52 |
| | If you can suggest a command i can execute | 12:01.17 |
| | them | 12:01.24 |
| Robin_Watts | OK, well, in that window, do: git clone http://git.ghostscript.com/ghostpdl.git ghostpdl | 12:01.25 |
| | That should clone you a copy into ghostpdl. | 12:01.34 |
| mikkado | Cloning into 'ghostpdl'... | 12:02.48 |
| | So, result is: | 13:04.51 |
| | error: The requested URL returned error: 500The number of HTTP requests per minute exceeded the configured limit. Contact you your forefront TMG administrator. | 13:06.25 |
| | (curl_ersult=22, http_code=500, sha1=2d957f7.... | 13:06.57 |
| kens | mikkado : As far as I know we don't use Forefront (its a Microsoft product), is it possible this is running at your end ? | 13:13.19 |
| | Forefront TMG = Microsoft Forefront Threat Management Gateway | 13:14.30 |
| mikkado | oh may be I shoud push my sys-admins )) | 13:17.42 |
| | thx | 13:17.49 |
| kens | No problem | 13:18.18 |
| henrys | tor8:hopefully the domain will get straightened out monday miles is out of town | 13:37.32 |
| ray_laptop | morning, all | 14:02.54 |
| kens | Hi Ray | 14:02.58 |
| ray_laptop | Hi, kens | 14:03.06 |
| | As you saw, my patch had problems on 66 tests (23 files) | 14:06.19 |
| kens | Yes, I did comment in the logs, I have some 'spare' time this afternoon, want me to take a quick look at the file(s) ? | 14:06.52 |
| ray_laptop | I don't understand why. I had filter=ppmraw so pdfwrite and ps2write were not involved | 14:07.33 |
| kens | Oh, I must have missed that | 14:07.44 |
| ray_laptop | I didn't say it on IRC | 14:08.01 |
| | sorry | 14:08.06 |
| kens | Ah, I guess that would explain it :-) | 14:08.15 |
| | You have a bmpcmp still there ? | 14:08.25 |
| | or rgression mail ? | 14:08.43 |
| | Hmm your last regression run said 8904 files have started producing errors, I guess that wasn't the one | 14:09.19 |
| | OK I see in your bmpcmp that there are some files with missing text, is it those ? | 14:10.02 |
| ray_laptop | that was the previous run, yes (with 4 pages of bmpcmp) | 14:10.47 |
| kens | OK let me poke at 067a for a minute,its a fairly easy one as I recall | 14:11.10 |
| kens | notes that they do all look like Tr problems | 14:11.59 |
| ray_laptop | I looked at one with debug in, and the place where PreserveTrMode changed was the one following the comment: % If the device doesn't handle text rendering modes then we now have a suitable | 14:12.38 |
| kens | OK the intriguing question is why the value should ever change, its not supposed to | 14:13.14 |
| | All the devices either have it hard-wired, or not present | 14:13.27 |
| ray_laptop | so, putting back that "dynamic" check fixed 067a and all but 4 other files | 14:13.35 |
| chrisl | Isn't there some crazy nonsense that we always somehow load pdfwrite even when it's not the requested device? | 14:13.48 |
| kens | I oculd believe pdfwrite pushing another deice that caused a different response, but ppmraw shouldn't | 14:13.58 |
| | chrisl yes indeed we do | 14:14.05 |
| chrisl | So if pdfwrite was in force when the initial check is done.... | 14:14.25 |
| kens | True, but I think it should not be because the PDF interpreter isn't started until after the device changeover is done (I think) | 14:14.55 |
| chrisl | I wasn't sure where Ray had put the check.... | 14:15.27 |
| kens | Well, I assume its in the PDF interpreter :-) | 14:15.38 |
| ray_laptop | the really STRANGE thing, is that on that file (067a) the check above that section (just before the comment % NB we must have Tr at least 4 or the test above would have) returned 'false', but the later check returned 'true' | 14:16.36 |
| | chrisl: you can look at the bottom of my regression run to see my changes | 14:18.09 |
| | kens: chrisl: do either of you want the patch ? | 14:19.37 |
| kens | I can pick it up if I need it, I'm just looking at the PostScript at the moment (the PDF interpreter PS) | 14:19.59 |
| chrisl | ray_laptop: I'm in the middle of my own stuff right now... | 14:20.08 |
| kens | Trying to remember what this all does | 14:20.10 |
| ray_laptop | Note that this run also had the color remap changes in, but that regression run was clean | 14:20.10 |
| | chrisl: font cache ? | 14:20.19 |
| chrisl | ray_laptop: font cacheing, yes | 14:20.43 |
| kens | ray_laptop : there is an inversion in the logic there, how did you check the return value ? The return value should be 'not present' which in effect does a 'cleartomark //false' | 14:24.05 |
| ray_laptop | kens: what I did was to capture the PreserveTrMode setting from the device at the start of the page (right after where PDFSave was done in pdf_main) and then replace the getdeviceparams with using the saved value in pdf_ops.ps | 14:24.14 |
| kens | ray_laptop : yes..... | 14:24.29 |
| | But the point is that the return value gets inverted at the second test | 14:24.43 |
| ray_laptop | kens: oops. I missed that | 14:24.55 |
| kens | THere's a 'not' right in front of the if clause | 14:25.10 |
| ray_laptop | the code looks mostly alike :-/ | 14:25.16 |
| | kens: thanks for spotting that | 14:25.32 |
| kens | NP, does it help do you think ? | 14:25.45 |
| ray_laptop | kens: I'll let you know. At least it explains why I saw something different for that part of the code | 14:26.33 |
| | twisty passages, mostly alike :-) | 14:28.19 |
| kens | Well, the thing is I wanted to do something if it *wasn't* true, as opposed to if it was.... | 14:28.45 |
| ray_laptop | kens: I realize that (now) | 14:29.09 |
| kens | There are probably other similar cases | 14:29.25 |
| ray_laptop | the other cases were all OK (no 'not' in the original code) | 14:30.52 |
| | now I have to look at the other things my patch honked up. Thanks, kens | 14:31.38 |
| kens | No problem. I'd still prefer to do this a different (faster) way though | 14:32.04 |
| ray_laptop | The following 8904 regression file(s) have started producing errors... | 14:32.08 |
| kens | Yeah I saw that, didn't look good | 14:32.22 |
| ray_laptop | kens: doing a getdeviceparams once at the start of the page is not a performance hit | 14:32.37 |
| kens | It does lack flexibility though, what if I push a device (eg pdfwrite/ps2write) which changes the behaviour.... | 14:33.06 |
| ray_laptop | and the way I did it captured ALL of the parameters of interest with a single currentpagedevice (which gets a dict of all of the params) | 14:33.21 |
| | kens: how can you push a pdfwrite device during a page ??? | 14:33.52 |
| kens | Not a pdfwrite device, but what if pdfwrite poushes a flattening image device ? | 14:34.12 |
| ray_laptop | kens: right. so PreserveTrMode will be true for pdfwrite, right ? | 14:35.14 |
| kens | Yes | 14:35.21 |
| | But not for an image device doing transparency flattening | 14:35.34 |
| ray_laptop | and presumably it needs to be false for the "normal" flattening to work ? | 14:35.37 |
| | well, for cust 532, that isn't an issue | 14:37.46 |
| kens | I would think so yes | 14:37.48 |
| | Sure, but if this is worth having, why limit it to that customer ? | 14:38.05 |
| | more performance = better | 14:38.28 |
| ray_laptop | kens: clearly worth having. For that QL file (WWTTN1CT) I got 30% improvement of the parsing time on my laptop | 14:41.27 |
| | and 10% on the PLRM | 14:41.37 |
| kens | which makes me think again we hsould do something different for these parameters | 14:41.55 |
| ray_laptop | kens: If you want to do this right, adding a dev_spec_op usable from PS, that's fine. The problem is that the spec_op functions are invoked by enum (gxdevsop.h) | 14:47.30 |
| | The other approach is to just have a PS operator that examines the device structure, and move those parameters to the gx_device part of the struct (so they are always present) | 14:49.16 |
| kens | I'd rather do a spec op and I htink its feasible to add a gneric 'get paramtere' to the enum | 14:50.08 |
| | Lets get your case working first, then I'll look into it | 14:50.24 |
| ray_laptop | kens: the problem with get_params is that it does ALL of the parameters. There is no way to just get a single parameter from a device | 14:51.21 |
| kens | And its hideously slow | 14:51.31 |
| ray_laptop | kens: right. because it is getting all the params | 14:51.53 |
| kens | asLike I said, lets get this working for you first, then if it looks good open a bug for me to address it | 14:53.19 |
| ray_laptop | kens: I see the problem with my error files (affects ALL pdfwrite/ps2write) in the way I collected the settings | 15:02.39 |
| kens | Presumably you cna fix it though.... | 15:03.21 |
| ray_laptop | kens: fixed. I was in a hurry and didn't handle the case where the device had the parameters | 15:06.26 |
| kens | Ah :-) | 15:06.37 |
| malc | http://cs.sjsu.edu/~mak/CS185C/KnuthStructuredProgrammingGoTo.pdf | 15:10.24 |
| | first few pages fail to render | 15:10.32 |
| kens | Pleae open a bug report if you thinkyou have found a problem | 15:11.29 |
| malc | http://bugs.ghostscript.com/show_bug.cgi?id=695171 | 15:13.56 |
| chrisl | malc: it's generally preferable if you attach the problem file to the bug - that way it won't disappear before we get a chance to look at it | 15:15.39 |
| | malc: seems to work okay for me.... | 15:19.19 |
| malc | tmp$ ~/x/rcs/git/mupdf/build/release/mupdf-x11 KnuthStructuredProgrammingGoTo.pdf | 15:20.04 |
| | warning: unknown keyword: '' | 15:20.07 |
| | might be an endianness problem, i'm on PPC | 15:20.17 |
| | or perhaps char related | 15:20.35 |
| kens | Oh MuPDF | 15:20.43 |
| chrisl | Possibly useful information like that would be in the bug report | 15:21.08 |
| Robin_Watts | henrys: You about? | 15:22.30 |
| malc | chrisl: it's a regression, but i'd rather not go bisecting it unless absolutely necessary | 15:23.44 |
| Robin_Watts | malc: If it's a big endian thing, then it will be a lot of work for us to hunt for as we don't have big endian machines easily to hand. | 15:29.37 |
| chrisl | malc: well, unless you state the specifics of the problem in the bug report (like the platform), it'll just get closed as "works for me" | 15:29.54 |
| Robin_Watts | Bisecting it would make it vastly more likely to get fixed. (After all, if you can't be bothered to bisect it when it doesn't work for you, why should we when it works for us ? :) ) | 15:30.40 |
| malc | Robin_Watts: pride? | 15:31.16 |
| ray_laptop | malc: if it works for us, we CAN'T bisect it | 15:31.44 |
| Robin_Watts | malc: pride indeed, but with recent events, the workload here is now such that we don't have time to go hunting for stuff. | 15:31.52 |
| ray_laptop | malc: plus we don't have ready access to PPC machines | 15:32.28 |
| malc | Robin_Watts: recent events? | 15:33.11 |
| ray_laptop | malc: we acquired a whole new product line -- SmartOffice and swallowing that is time consuming | 15:34.12 |
| malc | ray_laptop: okay, it's not that i'm against bisecting, it's just this PPC is sortof on the slow end of things for this kind of work | 15:34.17 |
| | ray_laptop: oh, okay | 15:34.26 |
| ray_laptop | malc: I bet our big endian machines are even slower than yours | 15:34.45 |
| malc | ray_laptop: arm-be? mips? | 15:35.19 |
| Robin_Watts | malc: Yeah, we're still at the "dislocating our jaw" phase. | 15:35.30 |
| chrisl | Interestingly Acrobat 9 can't pre-flight the file - gives an error reading contents stream | 15:35.39 |
| ray_laptop | ARM is the most easily available | 15:35.47 |
| | and those are pig slow | 15:36.10 |
| chrisl | All the ARMS we have around are little endian aren't they? | 15:36.13 |
| Robin_Watts | arm-be is a non-starter. I refuse to acknowledge it's existence :) | 15:36.20 |
| ray_laptop | agrees | 15:36.30 |
| | malc: one of our guys has an old Mac PPC | 15:37.04 |
| malc | ray_laptop: that's what i have :) | 15:37.11 |
| ray_laptop | but we can't ssh to it, AFAIK | 15:37.21 |
| chrisl | I have a PPC Mac Mini here - but I'm also busy with other stuff. I'm happy to look at it, at some point..... | 15:37.43 |
| | Assuming the dratted thing still works, of course! | 15:38.09 |
| malc | it is a PPC Mac Mini :) | 15:38.24 |
| ray_laptop | chrisl: I also have an OLD mac mini. It's been at least 3 years since I powered it on | 15:38.48 |
| malc | Robin_Watts: any arm would at least tell whether it's signedness of char is at play | 15:38.49 |
| chrisl | It's been a bit flaky the last few times I used it | 15:39.17 |
| Robin_Watts | malc: Well, we've not had arm android device complaints, so... | 15:39.17 |
| chrisl | malc: and you still haven't updated the bug with the platform information it.... | 15:41.14 |
| malc | chrisl: too busy bisecting... | 15:42.25 |
| ray_laptop | kens: got my problems sorted out (all but one that I can't reproduce locally) | 15:45.42 |
| kens | What's the odd one ? | 15:45.54 |
| ray_laptop | kens: tests_private/comparefiles/Bug693365.pdf.ppmraw.300.0 | 15:49.32 |
| kens | wAh I think that's one that's been indeterminate recently, just a moment | 15:49.53 |
| chrisl | ray_laptop: so, I have changes in the PDF substitution code which generate an XUID based on the real font's UniqueID/XUID and the PDF object number of the font object.... so the cacheing code retains the glyphs even though the font is destroyed at the end of the page | 15:50.42 |
| kens | No, I'm wrong its not that one | 15:50.43 |
| ray_laptop | strange. the bmpcmp run came up with files that have differences that are NOT on the report ??? tests_private/comparefiles/Bug692502.eps.pdf.ppmraw.300.0 and tests_private/comparefiles/Bug693538.pdf.ps.ppmraw.72.0 | 15:51.54 |
| | chrisl: AWESOME! | 15:55.08 |
| | chrisl: did you put that in the customer's code, or do you want me to port it ? | 15:55.31 |
| | chrisl: and have you done a regression of the change ? | 15:58.25 |
| | chrisl: (it looks like you did do a regression run about an hour ago) | 16:00.05 |
| chrisl | ray_laptop: on phone | 16:04.37 |
| henrys_laptop | mvrhel_laptop, Robin_Watts : debugging on vs 2013 I'm getting "basepath" can't be relative when starting the debugger. I don't remember that happening before. | 16:17.33 |
| Robin_Watts | debugging what? | 16:17.47 |
| henrys_laptop | ghostscript | 16:18.04 |
| mvrhel_laptop | henrys_laptop: I have never had a problem with vs 2013 and gs | 16:18.24 |
| | :( darn the sot build failed | 16:18.36 |
| henrys_laptop | I've probably horked something up | 16:19.04 |
| mvrhel_laptop | some python command failed to occur | 16:19.47 |
| Robin_Watts | henrys_laptop: I only have VS2010, and I don't see a "basepath" configuration anywhere. | 16:19.47 |
| mvrhel_laptop | digging a bit before I bug Robin_Watts | 16:20.28 |
| Robin_Watts | mvrhel_laptop: bug away, it might be something I recognise. | 16:20.51 |
| mvrhel_laptop | Failed to execute command python C:\vrhel\Artifex_laptop\git_sot\sot\epage/foundation/libraries/io/fs/mkromfss2.py .... | 16:21.51 |
| henrys_laptop | Actually it is basePath - it is a string in a generated file | 16:21.56 |
| | let me clean and rebuild | 16:22.15 |
| Robin_Watts | henrys_laptop: Which file? | 16:22.23 |
| henrys_laptop | I'm trying out circ a chrome irc extension seems to work ok. | 16:22.34 |
| Robin_Watts | mvrhel_laptop: Anything earlier than that? | 16:23.00 |
| henrys_laptop | Ghostpdl.sdf | 16:23.01 |
| Robin_Watts | mvrhel_laptop: Are you on master ? | 16:23.22 |
| mvrhel_laptop | yes I am on master | 16:23.49 |
| henrys_laptop | let me do a clean make and try to reproduce it. | 16:23.56 |
| Robin_Watts | mkromfss2.py is something I added since SO came to Aftifex, so it's probably my fault. | 16:24.38 |
| | mvrhel_laptop: Can you pastebin the error messages somewhere? | 16:26.24 |
| mvrhel_laptop | Robin_Watts: hold on let me build again so I just have the erors | 16:26.37 |
| | then I will pastebin | 16:26.41 |
| henrys_laptop | Robin_Watts, mvrhel_laptop do you guys usually use the project in Ghostpdl/win32 for ghostscript or the one in gs/ | 16:26.55 |
| | ? | 16:26.56 |
| mvrhel_laptop | ghostpdl | 16:27.09 |
| Robin_Watts | The solution in ghostpdl is the one to use. | 16:27.29 |
| henrys_laptop | okay that's what I was using let's see if it goes wrong again | 16:27.51 |
| mvrhel_laptop | Robin_Watts: http://pastebin.com/iFwxL4wg | 16:28.22 |
| Robin_Watts | The reason the vcproj for gs is in gs rather than with the solution, is for historical reasons; when we used to do a separate gs source release, it could be useful to be there. | 16:28.37 |
| | mvrhel_laptop: Ah! | 16:30.17 |
| | You were trying to "Build Solution". | 16:30.25 |
| | Don't do that. | 16:30.27 |
| mvrhel_laptop | ok | 16:30.32 |
| | I did look at the readme | 16:30.38 |
| Robin_Watts | Just try to build test-shell for now. | 16:30.55 |
| | SOT has all the files in, but can't be built itself. | 16:31.37 |
| mvrhel_laptop | ok | 16:31.45 |
| | so still some errors | 16:31.55 |
| | let me pastbin those | 16:31.59 |
| | Robin_Watts: http://pastebin.com/qaHtdt0g | 16:32.38 |
| henrys_laptop | something nuts is happening I was forced to login to ms this time, something is seriously broken | 16:33.58 |
| ray_laptop | chrisl: still on phone ? | 16:35.26 |
| chrisl | ray_laptop: yes | 16:35.37 |
| malc | Robin_Watts: 551de42088c58dc69fba06fb53e36c2ddb12367f culprit | 16:36.59 |
| chrisl | ray_laptop: back now..... | 16:40.49 |
| | ray_laptop: so, yes cluster tested - there is one file I need to look at, which is strange as it's a single page file, so really shouldn't be affected! | 16:41.25 |
| henrys_laptop | bbiab | 16:42.55 |
| chrisl | ray_laptop: The net result is cutting the number of times the glyph rendering is called from 7070 times down to 3039 times - but (you must have known there would be a "but") despite cutting glyph rendering calls in half, it actually runs marginally slower on my Linux box :-( | 16:43.03 |
| ray_laptop | chrisl: I wonder why there are so many calls still | 16:46.58 |
| | the font is the same on all pages and there are only two sizes of fonts used (10 and 12) | 16:47.56 |
| | and the text for the size 12 font is the same on all pages | 16:48.26 |
| chrisl | There may be any number of reasons we can't use the cached bitmap every time | 16:48.48 |
| ray_laptop | chrisl: BTW, on the simulator, there are only 4,274 calls to FAPI_do_char to do the rendering | 16:52.18 |
| chrisl | ray_laptop: I'm on the current master code | 16:52.41 |
| ray_laptop | so your numbers are a little suspect | 16:52.41 |
| kens | Goodnight all | 16:52.46 |
| ray_laptop | kens: g'nite | 16:52.54 |
| chrisl | ray_laptop: how are you gathering the numbers? | 16:55.20 |
| ray_laptop | chrisl: There _are_ two fonts used, but there are only two words used from the Italic font | 16:55.31 |
| | chrisl: from Len's excel spreadsheet | 16:56.05 |
| | chrisl: hold on while I double check with the simulator | 16:56.28 |
| chrisl | ray_laptop: well, I put a static variable in gs_fapi_do_char() and increment it on every all, then print it out when we complete, so.... | 16:57.39 |
| ray_laptop | chrisl: I have to rebuild. I hadn't rebuilt since I cleaned it out to zip it up for you :-( It'll be a bit... | 16:59.29 |
| chrisl | ray_laptop: anyway, my point is, I need to look at why with a lower call count, it's actually slower - maybe streamline some of the Postscript that I've added | 17:00.31 |
| ray_laptop | chrisl: if the PS is only for Tf ops, then it shouldn't be invoked frequently -- only once on some pages and three or four on others | 17:01.38 |
| | chrisl: can you shoot me a patch to try on my machine ? | 17:02.19 |
| chrisl | ray_laptop: I'll do that in a little while | 17:02.54 |
| | I'm just running a profile to see if it highlights anything | 17:03.47 |
| henrys | Robin_Watts, mvrhel_laptop and both of you are using the relative settings for command and working directory from the Readme? | 17:05.02 |
| chrisl | ray_laptop: gprof agrees with my call counts - 7070 before, 3039 with my changes | 17:05.08 |
| Robin_Watts | henrys: For debugging? | 17:05.15 |
| ray_laptop | chrisl: with the simulator and using breakpoint 'hit count' I get 4,158 hits on FAPI_do_char | 17:05.21 |
| henrys | Robin_Watts: yes | 17:05.42 |
| chrisl | ray_laptop: like I said, I'm using the master code, on the 9.06 release, or the 532 code | 17:05.44 |
| henrys | hold on I think I missed something | 17:06.52 |
| Robin_Watts | henrys: It is possible that they have disallowed relative things in later VS. | 17:06.53 |
| | In which case, you might need to use $(ProjectDir)\... etc | 17:07.14 |
| henrys | Robin_Watts: maybe wonder why it works for mvrhel_laptop | 17:09.40 |
| | ? | 17:09.43 |
| Robin_Watts | henrys: Maybe he put full paths in? | 17:10.05 |
| ray_laptop | chrisl: patch, please ? | 17:10.33 |
| | that way you don't have to mess with their code :-) | 17:11.27 |
| chrisl | ray_laptop: http://git.ghostscript.com/?p=user/chrisl/ghostpdl.git;a=commitdiff;h=62b5c30 | 17:14.07 |
| ray_laptop | chrisl: thanks. I'll give it a whirl on their code. | 17:14.39 |
| chrisl | ray_laptop: oh, and I'm not using the UFST as I've been tracking down a few issues that the cluster highlighted | 17:15.01 |
| henrys | Robin_Watts: well absolutes do work, but we should probably save the docs if mvrhel_laptop has had the same experience | 17:16.28 |
| | s/save/change | 17:16.39 |
| Robin_Watts | henrys: Can you try using $(ProjectDir)/... please? | 17:17.00 |
| mvrhel_laptop | hold on let me look | 17:17.11 |
| Robin_Watts | if that works, we can update the docs to that and they stay relative. | 17:17.12 |
| mvrhel_laptop | for the executable I have full path in there. dont call why though. in my command args, everything is relative to the working directory | 17:19.25 |
| henrys | mvrhel_laptop: and the working directory is ".." | 17:19.47 |
| | ? | 17:19.49 |
| mvrhel_laptop | . | 17:19.58 |
| henrys | hmph | 17:20.16 |
| | mvrhel_laptop: trying to get the ReadMe.txt sync'd up | 17:20.49 |
| | checking project dir | 17:20.58 |
| chrisl | ray_laptop: the call count disparity is from the width matching code that 532 replace with their MM font substitution | 17:23.35 |
| henrys | Robin_Watts: ProjectDir seems to work for the "command" | 17:23.46 |
| Robin_Watts | Sounds, from what michael says, that that's the problematic one. | 17:24.32 |
| chrisl | Removing the width matching code, the call counts drop to 4158 before and 127 after my XUID changes - but the latter is still slower for me :-( | 17:25.23 |
| | ray_laptop: ^^ | 17:25.35 |
| henrys | Robin_Watts: yes ".." in the working directory seems okay. | 17:26.24 |
| Robin_Watts | henrys: So update the docs to use $(ProjectDir) and everyone is happy? That should work in old versions too. | 17:26.48 |
| | This is something MS changed in recent VS. | 17:26.56 |
| henrys | Robin_Watts: can't this be baked into the solution - the only thing the user needs to change is arguments? | 17:27.20 |
| Robin_Watts | henrys: Sadly on VS2005/8 solutions, the debugging settings are saved 'per user'. | 17:27.51 |
| | hence they can't go into source control. | 17:28.04 |
| henrys | Robin_Watts: okay | 17:28.16 |
| Robin_Watts | On vs2010, it's different. | 17:28.20 |
| | I tried, honest :) | 17:28.30 |
| ray_laptop | chrisl: OK, thanks. I've ported your patch and am trying it now... | 17:38.25 |
| | chrisl: let me say it again: AWESOME ! Now I get 127 calls to FAPI_do_char :-) | 17:40.15 |
| chrisl | ray_laptop: cool, *BUT* as I said, it isn't any faster for me - which is *SO* strange :-( | 17:40.52 |
| ray_laptop | well, I'll shoot it off to them and let them try it on their target | 17:41.25 |
| chrisl | ray_laptop: okay, I *would* like to tidy up the patch a bit on Monday - I'd do it over the weekend, but I'm busy both days | 17:42.07 |
| | ray_laptop: I wonder if using the XUID is slowing things down..... | 17:43.32 |
| ray_laptop | chrisl: what about the regression testing -- I notice there were quite a few differences on your last run. Is there anything to worry about ? | 17:50.05 |
| chrisl | ray_laptop: there are a few pixel differences because we use a cached glyph instead of render a new one, several false positives (differences not in glyphs). The one I was worried about is a *severly* broken file - so I'm not worried about it now | 17:52.00 |
| ray_laptop | chrisl: OK. Thanks. | 17:53.42 |
| chrisl | ray_laptop: the sumatra ones are all really badly broken files - those are more about handling the breakage gracefully than any real expectation of them rendering correctly | 17:53.43 |
| ray_laptop | chrisl: have a good week end | 17:53.50 |
| chrisl | ray_laptop: thanks - although, I know the strange performance behaviour is going to prey on my mind..... | 17:54.36 |
| | OKay, it's not using the XUID that slows it down..... | 17:56.57 |
| | using UniqueID shows the same characteristics | 17:58.11 |
| Robin_Watts | chrisl: Presumably you're worried that it's the comparison of the XUID that is taking time? | 17:59.30 |
| chrisl | Robin_Watts: that was my thought, yes | 17:59.50 |
| Robin_Watts | Compare it 10 times, and see if it makes a difference. | 17:59.53 |
| | If it doesn't then it's reasonable to assume that comparing it once wasn't a hardship. | 18:00.21 |
| | paulgardiner: (For the logs) 1 commit on robin/master (mupdf) for you. | 18:01.50 |
| chrisl | Robin_Watts: My thinking along those lines was because the UniqueID is an integer, the XUID is an arbitrary length array of integers - but we check it only at the font level (so rarely) not at the glyph level (which would be often) | 18:02.44 |
| Robin_Watts | chrisl: Right. I've worried about similar things in the past (with glyph caching in mupdf for one) | 18:03.31 |
| | It's hard to measure the "don't compare" vs "compare once" time, because the "compare once" time does less work due to having done the compare. | 18:04.56 |
| | So all you can tell is "how much time did doing the compare and avoiding some work save me" | 18:05.21 |
| | but if you "compare 10 times and act on it just once" you can get a direct measurement. | 18:05.48 |
| chrisl | Yeh, in this case, it was fairly easy to check it experimentally | 18:06.11 |
| | It was trivial to make the code use a UniqueID instead of an XUID, and run the job a few times. | 18:06.52 |
| | and it was a relief that wasn't the culprit because using a "patched" UniqueID did not give sufficient "uniqueness" and we got incorrect cache hits | 18:07.25 |
| ray_laptop | chrisl: we need gprof for the PS code :-) | 18:08.53 |
| chrisl | ray_laptop: I seem to remember someone did at least a partial profiler for PS at some point - but I suspect it was level 1 only, and would likely choke on our custom operators! | 18:10.07 |
| ray_laptop | chrisl: how often does the Widths checking run ? Once per font per page ? | 18:10.15 |
| chrisl | Yes | 18:10.24 |
| | ray_laptop: I originally looked at just using a few selected glyphs and Widths, but as I said, there was virtually no measurable hit on the hardware I could test, so didn't bother | 18:12.02 |
| ray_laptop | so remembering that you already checked a certain font and determined that you didn't have to adjust widths would help ? | 18:12.16 |
| chrisl | ray_laptop: yes, that's something I could do now I have access to the PDF obj number | 18:13.02 |
| ray_laptop | chrisl: are you actually rendering the glyph or just grabbing its advance width metric ? | 18:13.45 |
| chrisl | ray_laptop: we actually render the glyph in order to get the advance width | 18:14.21 |
| | ray_laptop: unfortunately, even though we know we're not drawing the glyph, the cache is still set up for it, and it throws a hissy fit if you then don't give it a bitmap | 18:15.46 |
| | ray_laptop: unfortunately, the font object does not survive the page boundary.... | 18:21.38 |
| | Anyway, I'll revisit this stuff on Monday, maybe light will dawn..... | 18:27.24 |
| | Forward 1 day (to 2014/04/19)>>> | |
IRC Logs