texmacs-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Texmacs-dev] How texmacs is so slow for my macro


From: Gubinelli Massimiliano
Subject: Re: [Texmacs-dev] How texmacs is so slow for my macro
Date: Thu, 7 Apr 2011 11:44:21 +0200

Hi Sam,
I guess that you approach could work, I would have done the same. Unfortunately the only one well acquainted with TeXmacs macro handling optimizations (to my knowledge) is Joris and I do not know if in this moment he has the time to follow the discussion on the list.

It would be interesting if you continue to report your progress to the list, so that we can build some knowledge on macro writing techniques. Ideally we would need a wiki to gather all this....

good luck!

max




On 7 avr. 11, at 10:47, Sam Liddicott wrote:


I'm supposing that the reason the whole document is "re-processed" when I insert a list item- even when it is the last use of that counter - is the way texmacs tries to optimise, I'm guessing that it tracks which macros change which global data.

As I use a single macro for all of my chunks (each having a counter) my macro gets marked as touching each of these counters, and so anything else that also uses those counters has to gen "re- processed" if the counter changes.

If I follow the texmacs style of defining a new command for each of my named chunks, I suppose that will also solve my problem. It would work along the lines of the new-list macro - and in fact it would work like a list macro with a custom counter that is not with'd to zero.

Please will a wizard confirm if this is likely to be so; for - and here is the problem - I don't want to have a different macro for each named code thread, I want the name to be a parameter.

If I am correct, will I still get the advantage with a wrapper like this:

<assign|nf-chunk|<\macro|name|body>
<compound|<merge|nf-chunk-|<arg|name>>>
</macro>>

Would texmacs be able to realise that nf-chunk was not the macro touching all the counters, but the inner macro?

This whole thing is based on speculation, and I'll try it of course... but I really hope for some dialog with one who knows...

Sam


On 06/04/11 15:50, Sam Liddicott wrote:


In my case I fixed the slowness with this at the end of my environment:

<if|<nf-last-chunklet?|<value|nf-name>>|<assign|<merge|code-line-| <value|nf-name>|-nr>|0>>

nf-last-chunklet? uses some hackery to know if it is the last instance of the environment (for a particular nf-name) in the document by looking to see if there is a label defined based on the chunklet counter with 1 added to it.

If it is the last chunklet, then the line counter does not need preserving, and zero-ing it keeps things quick.

Sam

On 06/04/11 14:11, Sam Liddicott wrote:


I've simplified the whole deal with a new definition of list that does not reset item-nr to 0:

<assign|list|<macro|item-render|item-transform|body|<with|current- item|<arg|item-render>|transform-item|<arg|item-transform>|<render- list|<arg|body>>>>>

<\enumerate>
<item>one

<item>two

<item>

<item>three

<item>four
</enumerate>

hello joe <value|item-nr>


the enumerate and "hello joe" line can be repeated a few thousand times to bring the same problem.

I guess it is because the texmacs document is a program. When a change is made, it has to be re-executed in it's entirety unless it that can be optimised out.

In some cases for me, though, the counter is never re-used again after the environment instance in which the new line is being inserted, so it could be optimised out...

So I need to talk to someone on the nature of these optimisations (if I am right).

Sam



_______________________________________________
Texmacs-dev mailing list
address@hidden
http://lists.gnu.org/mailman/listinfo/texmacs-dev




--
[FSF Associate Member #2325] <http://www.fsf.org/register_form?referrer=2325 >

<http://www.openrightsgroup.org/>

_______________________________________________
Texmacs-dev mailing list
address@hidden
http://lists.gnu.org/mailman/listinfo/texmacs-dev




reply via email to

[Prev in Thread] Current Thread [Next in Thread]