Developer forums (C::B DEVELOPMENT STRICTLY!) > CodeCompletion redesign
Regular expressions
JGM:
--- Quote from: Ceniza on June 14, 2008, 08:07:52 am ---I wouldn't mind sharing the document, but it's in Spanish. Maybe the library reference would be of more help, yet it's not as interesting to read as the document itself :P
--- End quote ---
My native language is spanish :D
Ceniza:
--- Quote from: JGM on June 14, 2008, 07:33:52 pm ---
--- Quote from: Ceniza on June 14, 2008, 08:07:52 am ---I wouldn't mind sharing the document, but it's in Spanish. Maybe the library reference would be of more help, yet it's not as interesting to read as the document itself :P
--- End quote ---
My native language is spanish :D
--- End quote ---
I know :D
If that means you want to read the file then suit yourself.
BTW, that's just a preliminary version... which I hope becomes the final one.
I also started writing the document about the creation process of the String type. So far it only has the preliminary analysis, but may be a good read too. Link.
JGM:
I was reading your project documents and liked very much the irc chat conversation :P I felt like the beginner. I haven't finished reading but I'm at page 37 (and reading) I can say that you could be a great professor (you are really good with words) :) Your university faculty should approve that immediately is an A++.
Also I partially read your document for the new string implementation class and it's true. I confronted all those things while implementing a csv reader and writer I made, reading one byte at time was pretty slow, opening the hole file at once was amazingly fast, but using a bigger buffer should help. There should be functions to detect the size of the string to store and if it's to big for memory to handle parse it using a big amount of buffer depending on the size of the string, else store it completely on memory and parse it there since it is much faster.
The reading was pretty cool, implementing all those things properly should produce a really high speed c/c++ parser.
Ceniza:
--- Quote from: JGM on June 16, 2008, 06:20:24 pm ---I was reading your project documents and liked very much the irc chat conversation :P I felt like the beginner. I haven't finished reading but I'm at page 37 (and reading) I can say that you could be a great professor (you are really good with words) :) Your university faculty should approve that immediately is an A++.
--- End quote ---
Heh, thanks. Actually, I was a bit afraid of having such an introduction for the document, but my thesis director said it was OK. I also handed over the document today. Let's hope I graduate soon :)
Thanks for the 'professor' thing too. In fact, two proposals that I've received have been to teach: one at the University and the other one in an English institution. The idea sounds nice, but I prefer to write programs at the moment. I could teach later :P
--- Quote from: JGM on June 16, 2008, 06:20:24 pm ---The reading was pretty cool, implementing all those things properly should produce a really high speed c/c++ parser.
--- End quote ---
That's the idea. I'm not completely satisfied by the speed of the current implementation. If you want to add a syntactic and semantic analysis too, the speed of the preprocessor should be very good. I'll finish that string type first, check the performance gain (or loss) and try to optimize for real after doing some profiling.
Ceniza:
Quick news: my thesis has been approved and was graded with a "sobresaliente". The meaning of that word is something like "pretty good or ~excellent". Thesis are graded like this in here: not-approved, approved, "sobresaliente" and laureate. Not bad :D
In other news... I've finished the document where I implement the new string type for the preprocessor. It also means that I've finished the whole thing. Quoting from my own document:
--- Quote from: http://ceniza666.googlepages.com/caost4ccp.html ---The tests used three different types of string: STDString, CCPString<SimpleAllocator> and CCPString<CCPStringAllocator>. Here are the averaged results:
STDString: 0.409 s
CCPString<SimpleAllocator>: 0.193 s
CCPString<CCPStringAllocator>: 0.182 s
For being a SWAG we achieved a 2.12x performance gain using SimpleAllocator and 2.25x using CCPStringAllocator. Not bad!
What about memory usage? Let's take a look:
STDString: 11864 KiB
CCPString<SimpleAllocator>: 11792 KiB
CCPString<CCPStringAllocator>: 18496 KiB
Now the situation changes a bit. When using the SimpleAllocator we save less than 1% of memory, but using CCPStringAllocator increases the memory usage by a 56%, both compared to the memory usage when using STDString. I'm still curious about it. It'd be a good idea to play with different values for blockSize and see how the program behaves.
For those who also care about executable size, here are the results for each case:
STDString: 266.87 KiB
CCPString<SimpleAllocator>: 210.80 KiB
CCPString<CCPStringAllocator>: 238.81 KiB
Overall, SimpleAllocator has the best performance/memory usage/executable size ratio. Still, CCPStringAllocator gives the highest performance, but not for much compared to SimpleAllocator (about 6%).
I'd say we achieved our goal.
--- End quote ---
More than a 2x performance gain, and the library itself can be optimized too.
Next step: the painful parser.
Finally, to comply with my own disclaimer:
--- Quote from: Disclaimer ---This document is copyrighted by me (Paúl Andrés Jiménez). If you reproduce this file or parts of it in your website or a document, print it, save it, borrow it, share it, whatever... you're gonna Burn in Hell (it's actually a nice song by Dimmu Borgir). If you try to take ownership of this file, I'll f*cking sue you! That is, if I ever find out that you did. If burning in Hell is good enough for you, just don't forget to include this disclaimer. Also, all the names of companies, products and such are owned by their owners (doh!).
--- End quote ---
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version