View Single Post
Old 08-30-2010, 04:10 PM   #61
nrapallo
GuteBook/Mobi2IMP Creator
nrapallo ought to be getting tired of karma fortunes by now.nrapallo ought to be getting tired of karma fortunes by now.nrapallo ought to be getting tired of karma fortunes by now.nrapallo ought to be getting tired of karma fortunes by now.nrapallo ought to be getting tired of karma fortunes by now.nrapallo ought to be getting tired of karma fortunes by now.nrapallo ought to be getting tired of karma fortunes by now.nrapallo ought to be getting tired of karma fortunes by now.nrapallo ought to be getting tired of karma fortunes by now.nrapallo ought to be getting tired of karma fortunes by now.nrapallo ought to be getting tired of karma fortunes by now.
 
nrapallo's Avatar
 
Posts: 2,958
Karma: 2530691
Join Date: Dec 2007
Location: Toronto, Canada
Device: REB1200 EBW1150 Device: T1 NSTG iLiad_v2 NC Device: Asus_TF Next1 WPDN
Quote:
Originally Posted by Westlyn View Post
I find that any .IMP more than about 100k takes an ever increasing time eg 400Kb takes about 20 minutes but 1500K takes about 4 hours and a 2500Kb IMP hadn't produced html after 7 or 8 hours, so there seems to be an exponential-like increase in processing time as the file size increases.

IMP_DUMP seems to be much less size affected with the same 1500Kb file taking less than 30 seconds to output the txt file.
IMP_DUMP just decompresses the text that was compressed as part of the .imp build process. It basically is a decompressor written in C and is extremely fast since it does no "processing" on THAT text.

I too do find the writing of this html file extremely slow, but it is a more complex process than just decompressing the text. It has to search/look-up the 'styles' used for each span of text and insert proper paragraph / new page breaks. There's even "special codes" spots that deal with images/tables/etc...

Perhaps Michael can review same for better efficiencies and try to curb the exponential growth in time when compared to file size.

Quote:
The file that takes 4 hours also generates a .html file where the text is unreadable but the imp_dump .txt file is readable

eg Output html in browser from ConvertIMPGUI:

Code:
„ ™ P) M a o “ % 
…s C i’ +' · 

è’ 7 < F q F k •s ™¹, s Á™ ™ K ˆ 

7t 7 ™ ™ K r ¡ ˜ sf aÁ™ ]4c q ‘{ Í£ ±c’ F\2 ˜ { ^ cv  › K
but the imp_dump output is readable; but is output with unix not windows line end termination. My highlighting of the line end chars.

Code:
"LF"PROLOGUE "LF"	"LF"I have a story to tell you. It has many beginnings, and perhaps one ending. Perhaps not. Beginnings and endings are contingent things anyway; inventions, devices. Where does any story really begin? There is always context, always an encompassingly greater epic, always something before the described events, unless we are to start every story with, 'BANG! Expand! Sssss . . .', then itemise the whole subsequent history of the universe before settling down, at last, to the particular tale in question. Similarly, no ending is final, unless it is the end of all things . . . "LF"Nevertheless
I must be being dense today but I couldn't see how to attach a file to a private email in this forum. So bear with me until I find out how.
You can't, so stop looking... Best to send Michael a private message asking him for his email or better still provide him with your off-site email and then you can make a "connection" for further email attachments...

Quote:
I'll send you a zip file with the .imp, the .html and .txt output from ConvertIMPGUI and IPM_dump. Hopefully that would make it easier to track down the issue. I'm assuming the massive performance hit is maybe related to the output formatting issue.

Thanks again for being willing to take a look
I'm interest in this too!
nrapallo is offline   Reply With Quote