hodapp/prosha
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Minor updates to README

Browse Source
This commit is contained in:
Chris Hodapp 2021-07-26 16:48:32 -04:00
parent 670b7859a9
commit 1c9053a5ad
1 changed files with 2 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
README.md
View File

@ -67,7 +67,7 @@ A lot of what I wrote here ended up just being a buggy, half-assed
interpreter for a buggy, half-assed EDSL/minilanguage. interpreter for a buggy, half-assed EDSL/minilanguage.
(Greenspun's Tenth Rule of Programming, anyone?) (Greenspun's Tenth Rule of Programming, anyone?)
On top of this, my implementation is pretty slow when it is On top of this, my implementation was pretty slow when it was
using a large number of rules each producing small geometry using a large number of rules each producing small geometry
(which is almost literally the only way it *can* be used (which is almost literally the only way it *can* be used
if you want to produce a fairly complex mesh). I did some if you want to produce a fairly complex mesh). I did some
@ -75,7 +75,7 @@ profiling some months ago that showed I was spending the
vast majority of my time in `extend()` and `clone()` for vast majority of my time in `extend()` and `clone()` for
`Vec` - and so I could probably see some huge performance `Vec` - and so I could probably see some huge performance
gains if I could simply pre-allocate vectors and share geometry gains if I could simply pre-allocate vectors and share geometry
more. Also, I'm pretty sure this code does some very task-parallel more. Also, I'm pretty sure this code did some very task-parallel
elements (e.g. anytime a rule branches), and multithreading should elements (e.g. anytime a rule branches), and multithreading should
be able to exploit this if I care. be able to exploit this if I care.