Nah - I'm not saying that memory is cheap (or that cache misses aren't important) - just saying that int -> char casting isn't the culprit here. The parser is a really low level algorithm that is responsible for reading int from the bytes of a file and figuring out the appropriate value to convert them to. Sometimes it's a char, sometimes not. By the time the results of the parse are pulled from the parser, they are not ints anymore. It's not like we are carrying around a massive block of int[] to represent a string or anything like that.
The profiling results from Giovanni indicate that the call to isWhitespace accounts for less than 1% of runtime, while the calls to RandomAccessForOrArray.read() (and it's Mapped IO derivatives) and PRTokeniser.nextToken() consume 17% combined. It's probably best to focus on those. Mike Marchywka-2 wrote: > > > > > > So you are doing everything internally with 32 bit "chars?" > Not a big deal but if these are mostly zero there may be > better ways to represent and save memory. You may say, "well > RAM is cheap" but that doesn't matter since low level caches > are fixed but I guess you can get a bigger disk and say VM is unlimited. > > > > >> are actually consuming run time, and this method isn't one of them (no >> matter how much it could be optimized). > > The only person with data claimed otherwise :) > > > >> >> > tp://1t3xt.info/tutorials/keywords/ > > -- View this message in context: http://old.nabble.com/performance-follow-up-tp28322800p28344478.html Sent from the iText - General mailing list archive at Nabble.com. ------------------------------------------------------------------------------ _______________________________________________ iText-questions mailing list iText-questions@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/itext-questions Buy the iText book: http://www.itextpdf.com/book/ Check the site with examples before you ask questions: http://www.1t3xt.info/examples/ You can also search the keywords list: http://1t3xt.info/tutorials/keywords/
