On Mon, Feb 7, 2011 at 1:59 PM, Bill McCarthy <bill.mccarthy.li...@live.com.au> wrote: > If the templates don't change often, but are used somewhat more often, then > it might be worth pre-processing them: that is parse them initially, and > spit them out in parts with a directive file. Then you simply read the > directive file and stitch the parts together. > > Eg: > Long text <%=placeholder1 %> more text <%=someotherplaceholder%> even more > text > > Would be preprocessed into 3 files and one directive file. The directive > file would just list the parts and placeholder sequence: eg: > > <parts> > <part @index=0 @type=file>file1.txt</part> > <part @index=0 @type=replacement>placeholder1</part> > <part @index=0 @type=file>file2.txt</part> > <part @index=0 @type=replacement> someotherplaceholder</part> > <part @index=0 @type=file>file3.txt</part> > </parts> > > This would save you re-parsing the templates. Whether or not it is worth > the effort in your case is something you'd have to decide on. I wouldn't > bother unless initial performance and/or you are doing a lot of re-use of > the templates. >
Thanks for that Bill this is actually something like what I considered. I shall re-examine it. > As to using a asp.net style parser, it's a possibility, but probably not > worth the overhead or time it would take to investigate another engine. > > > > |-----Original Message----- > |From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet- > |boun...@ozdotnet.com] On Behalf Of Bec Carter > |Sent: Monday, 7 February 2011 1:42 PM > |To: ozDotNet > |Subject: Re: Placeholders in large text file > | > |On Mon, Feb 7, 2011 at 1:33 PM, Michael Minutillo > |<michael.minuti...@gmail.com> wrote: > |> Well, if the template size isn't going change and this is the only app > |> running on the machine then so be it. Chances are good that neither of > |> those things is true. I'd still err on the side of having a single > |> line memory at a time because it's not like the optimization is making > |> it any harder to read or understand. > |> > | > |Yup template file will mostly likely not change and app will always run > locally > |as an exe. This sort of optimisation you suggested seems good enough to use > as > |it is fairly simple. > | > |...But I was kinda questioning the design of doing things this way at all. > It seems > |like what I want is a dynamic "page" (like a webform) that can run and spit > out > |text just like an asp page does.....so the placeholders would really be <%= > %> > |tags. Is something like this an option? Can I somehow run an asp.net page > |locally? Will this cause performance problems for 750megs of data which is > |around 70 pages? Am I going completely crazy? :-) > | > | > |> Michael M. Minutillo > |> Indiscriminate Information Sponge > |> Blog: http://wolfbyte-net.blogspot.com > |> > |> > |> On Mon, Feb 7, 2011 at 10:30 AM, mike smith <meski...@gmail.com> wrote: > |>> > |>> On Mon, Feb 7, 2011 at 12:49 PM, Michael Minutillo > |>> <michael.minuti...@gmail.com> wrote: > |>>> > |>>> If you're in .NET 4.0 land then I'd do something similar to this: > |>>> public string ReplaceTokens(string src) { /* ... */ } > |>>> File.WriteAllLines(outputFileName, > |>>> File.ReadLines(inputFileName).Select(ReplaceTokens)); > |>>> The ReadLines call (new to .NET 4.0) reads one line at a time and > |>>> returns it as you iterate over it so in theory you don't need to > |>>> have the whole file in memory. Don't use the ReadAllLines method on > |>>> a 750MB file which DOES read the whole thing in before you start. > |>>> > |>> > |>> > |>> Is that a real problem given physical RAM these days? If you're > |>> going to write multiple outputs from the one template file of 750 > |>> it's going to rapidly get more efficient to have the template in-ram. > Wait a > |moment. > |>> You don't work for Readers Digest, do you? I have no desire > |>> whatever to make them more efficient. > |>> -- > |>> Meski > |>> > |>> "Going to Starbucks for coffee is like going to prison for sex. Sure, > |>> you'll get it, but it's going to be rough" - Adam Hills > |> > |> > >
