Hey guys, longtime listener, second-time caller.
In my spare time after work, I've been chipping away on making a HTML/CSS compiler to make doing any kind of frontend work for web less painful.
https://github.com/SilbinaryWolf/fel
The problem with this project is that I'm a web developer full-time (PHP/HTML/CSS/JS) and so I'm not super experienced with managing memory myself and I feel like I've abused the pool pattern for this project to a ridiculous degree, causing unnecessary code complexity.
I'm just wondering in a general sense where I can simplify things in a way that is both performant and easier to manage.
For example, I was considering switching my CSS_Rule/AST structs to use an overloaded 'new' keyword wherein they can just allocate from a pool of those types based on a global allocator pointer/var. (Also not sure how to go about making this thread-safe assuming I need/want threading in the future)
Then instead of storing the children in an array named 'childRules', I'd have an array of ints referencing what that AST/CSS_Rule's parent is. Then to iterate over an AST/CSS_Rule's children, you just iterate over the 'parent int array' and find whatever items match the ID of the AST you want the children of.
I'm putting up everything I've got so far so that people can give me their 2-cents on my style and structure as there may be C/C++ features that would simplify the readability that I'm not aware of.
In my spare time after work, I've been chipping away on making a HTML/CSS compiler to make doing any kind of frontend work for web less painful.
https://github.com/SilbinaryWolf/fel
The problem with this project is that I'm a web developer full-time (PHP/HTML/CSS/JS) and so I'm not super experienced with managing memory myself and I feel like I've abused the pool pattern for this project to a ridiculous degree, causing unnecessary code complexity.
I'm just wondering in a general sense where I can simplify things in a way that is both performant and easier to manage.
For example, I was considering switching my CSS_Rule/AST structs to use an overloaded 'new' keyword wherein they can just allocate from a pool of those types based on a global allocator pointer/var. (Also not sure how to go about making this thread-safe assuming I need/want threading in the future)
Then instead of storing the children in an array named 'childRules', I'd have an array of ints referencing what that AST/CSS_Rule's parent is. Then to iterate over an AST/CSS_Rule's children, you just iterate over the 'parent int array' and find whatever items match the ID of the AST you want the children of.
I'm putting up everything I've got so far so that people can give me their 2-cents on my style and structure as there may be C/C++ features that would simplify the readability that I'm not aware of.
I'm not sure you need pool types (but it may be a good idea, I don't know). And pool is not the right term I think: a pool is an area of memory where you free items to re-use the memory for later allocation of an item of the same type.
What you can do (without doing special allocator for certain types) if you want to separate things in memory, is to have several memory region where you allocate special types.
Instead of arrays of ids (int) you can store direct pointers to parent / childs, that would work even if you change the way you allocate memory.
If you didn't notice performance problem yet, you should not think about it too much.
I'm not an expert so take all this with a grain of salt.
What you can do (without doing special allocator for certain types) if you want to separate things in memory, is to have several memory region where you allocate special types.
1 2 3 4 5 6 7 8 | // NOTE: This will most likely leave gaps in memory, if it's a concern, you may need a better system. MemoryBlock allMemory = getMemory( megabytes( 3 ) ); MemoryBlock CSSSelector = getSubBlock( &allMemory, megabytes( 1 ) ); MemoryBlock CSSProperty = getSubBlock( &allMemory, megabytes( 1 ) ); MemoryBlock CSSRule = getSubBlock( &allMemory, megabytes( 1 ) ); ... CSS_selector* selector = push_struct( &CSSSelector, CSS_selector ); ... |
Instead of arrays of ids (int) you can store direct pointers to parent / childs, that would work even if you change the way you allocate memory.
If you didn't notice performance problem yet, you should not think about it too much.
I'm not an expert so take all this with a grain of salt.
Edited by Simon Anciaux
on
Reason: Typo
My 2 cents:
In case you start profiling and find that GC hiccups are a problem:
This is a package from an abandoned game that was written in Go. They published their pool allocator separately. It's 100 lines of code. :)
link
In case you start profiling and find that GC hiccups are a problem:
This is a package from an abandoned game that was written in Go. They published their pool allocator separately. It's 100 lines of code. :)
link