[13:01] PeterThoeny: hi kenneth, harald (and sven in absense?)
[13:01] PeterThoeny: kenneth, how was france?
[13:01] HaraldJoerg: Hello!
[13:02] Lavr: Hi all. France was wonderful.
[13:02] PeterThoeny: which part di you go to?
[13:03] Lavr: Bretagne
[13:03] PeterThoeny: did you do some hiking?
[13:04] Lavr: Not much. More driving and walk around locally.
[13:04] Lavr: The coast on the north part is fantastic.
[13:04] Lavr: The tides are crazy there. 12 meters between high and low.
[13:04] PeterThoeny: warm enough to swim?
[13:04] *** Flenser has joined #twiki_edinburgh.
[13:04] PeterThoeny: wow
[13:05] PeterThoeny: hi sam
[13:05] *** Flenser is n=Miranda@twiki/developer/SamHasler (Sam Hasler)
[13:05] *** Flenser is on: #twiki_edinburgh #twiki 
[13:05] *** Flenser is using irc.freenode.net (Link: http://freenode.net/)http://freenode.net/
[13:05] *** End of /WHOIS.
[13:05] Flenser: hi
[13:05] Lavr: Hi
[13:05] PeterThoeny: btw, i got an e-mail with this question: "Are there any plans for a Twiki conference this year or next?"
[13:07] PeterThoeny: what do you think?
[13:08] HaraldJoerg: A lot of work to organize such a thing :-)
[13:08] PeterThoeny: i am considering informal twiki thursdays in the silicon valley
[13:08] PeterThoeny: but i am not sure if we have the critical mass for a twiki conference
[13:08] PeterThoeny: yes, lot of work to organize
[13:09] PeterThoeny: if done, possibly hook up to another conference
[13:10] PeterThoeny: not many people today
[13:10] PeterThoeny: shall we wait a bit more or start?
[13:11] HaraldJoerg: According to the logs #twiki is pretty quiet as well in these days...
[13:12] PeterThoeny: btw, i have to leave at +90 minutes
[13:12] PeterThoeny: bbq event with 4 families
[13:12] PeterThoeny: today is a holiday in the usa
[13:12] PeterThoeny: labor day
[13:12] Lavr: I probably also will leave early. I am a bit tired tonight.
[13:13] Lavr: I have started working a little on hotfix 3.
[13:13] PeterThoeny: 10K e-mail waiting at work?
[13:14] PeterThoeny: ok, lets start with the small group
[13:14] PeterThoeny: may be we can limit the number of items to discuss
[13:14] PeterThoeny: (Link: http://twiki.org/cgi-bin/view/Codev/EdinburghReleaseMeeting2006x09x04)http://twiki.org/cgi-bin/view/Codev/EdinburghReleaseMeeting2006x09x04
[13:14] PeterThoeny: who is moderating?
[13:15] PeterThoeny: who is taking notes?
[13:15] Lavr: I will probably not last the meeting out - but I can add the notes tomorrow based on log.
[13:15] PeterThoeny: i will moderate unless some else wants to
[13:16] PeterThoeny: ok then, settled
[13:16] PeterThoeny: proposed agenda: 
 1. Review Previous Action Items 
 2. Modify ChangeProposal for new TWiki Release 4.1 Process 
 3. Review proposed items
 4. Profiling framework for TWiki
[13:17] PeterThoeny: which one to skip? what to add?
[13:17] Flenser: skip 3
[13:17] PeterThoeny: agreed, not enough folks
[13:18] Flenser: 4? as Arthur's not here
[13:18] PeterThoeny: ok, lets do 1. Review Previous Action Items
[13:18] PeterThoeny: -- All: Profilling - few wishlist inputs. More very welcome. Agree to let Harald push this further
[13:19] PeterThoeny: harld, did you get more feedback?
[13:19] HaraldJoerg: Well, there has been a bit of collaboration with CDot about the commit I made.
[13:19] HaraldJoerg: Which lead to a re-thinking of bin/configure in general.
[13:20] PeterThoeny: is this what cdot implemented now?
[13:20] PeterThoeny: or part of?
[13:20] HaraldJoerg: Part of what CDot did. 
[13:20] HaraldJoerg: The "visible" part (in 4.1 terms) has been the possibility to install plugins via configure's web interface
[13:21] PeterThoeny: ok
[13:21] HaraldJoerg: The "invisible" part is the refactoring, which lead to a bit of discussion in r11384 (IIRC) and then in TWiki:Codev.ConfiguringConfigure
[13:23] PeterThoeny: ok, lets see if there are new action items for profiling when we discuss agenda item 4
[13:23] PeterThoeny: -- Kenneth: TWikiFn. Ask Meredith if she is committed to drive it further
[13:23] PeterThoeny: kenneth, any news?
[13:24] Lavr: Well. As far as I can see from looking at TWikiFn topics.... no activitity since July.
[13:24] Lavr: If she read the minutes I wrote from last meeting I would have expected at least a reaction.
[13:25] Lavr: Given we are now in September it seems TWikiFns are on hold until someone takes the time to pick it up.
[13:25] PeterThoeny: she disappeared from the twiki landscape
[13:25] PeterThoeny: could you send her an e-mail and ask?
[13:25] Lavr: I will.
[13:26] PeterThoeny: -- Rafael: Take a stab at defining the scope of finishing the work of implementing TWikiFn
[13:26] PeterThoeny: anyone recalls if rafael did this?
[13:27] Lavr: I remember him adding something but I cannot remember now in which topic.
[13:29] PeterThoeny: i just check Codev.TWikiFns, Codev.FnsAndMacrosDiscussion, Codev.TWikiFnsDiscussion
[13:29] PeterThoeny: but nothing there
[13:29] PeterThoeny: -- Kenneth: Clarify the veto on TWikiRelease04x01Process as it has been discussed today
[13:29] Lavr: Done
[13:29] PeterThoeny: yes
[13:29] PeterThoeny: -- All: Configure on DEVELOP
[13:30] PeterThoeny: done in twiki 4 branch
[13:30] PeterThoeny: -- PreInstallSmartEditAddOn
[13:30] PeterThoeny: -- Arthur: will try and look at code as time allows
[13:31] PeterThoeny: many people looked at this
[13:31] PeterThoeny: besides performance issue on ie it looks pretty good now
[13:31] Lavr: I still like the idea of including it in some form or shape. I do not know what happened with it the last 2 weeks.
[13:32] PeterThoeny: gael posted a new version on 18 aug
[13:32] PeterThoeny: some discussion happened after that, (Link: http://twiki.org/cgi-bin/view/Plugins/SmartEditAddOnDev)http://twiki.org/cgi-bin/view/Plugins/SmartEditAddOnDev
[13:33] PeterThoeny: ok, lets move on
[13:33] PeterThoeny: ---++  2. Modify ChangeProposal for new TWiki Release 4.1 Process
[13:34] PeterThoeny: i have not prepared anything yet
[13:34] Flenser: where is the new release process documented?
[13:34] PeterThoeny: we need to review the change proposal to reflect the revised process
[13:34] PeterThoeny: (Link: http://twiki.org/cgi-bin/view/Codev/TWikiRelease04x01Process)http://twiki.org/cgi-bin/view/Codev/TWikiRelease04x01Process
[13:35] PeterThoeny: the existing change proposal is documented at (Link: http://twiki.org/cgi-bin/view/Codev/ChangeProposal)http://twiki.org/cgi-bin/view/Codev/ChangeProposal
[13:35] PeterThoeny: i think we have two goals here
[13:35] Lavr: It would be good with more comments from the regular developers on Codev/TWikiRelease04x01Process since not all show up at these meetings.
[13:36] PeterThoeny: 1. incorporate new process into change proposal
[13:36] PeterThoeny: 2. simplyfy change proposal
[13:36] Flenser: as far as I can see the new process is only about how we use the form, it doesn't nesesitate any changes to it
[13:36] PeterThoeny: "simplify"
[13:37] Flenser: "simplify" should probably encompass the topic templates too, as I've noticed they're not used
[13:37] PeterThoeny: yes
[13:38] PeterThoeny: how is "raising a concern" reflected in the change proposal?
[13:38] PeterThoeny: the OutstandingIssues field could be used?
[13:39] Flenser: OutstandingIssues
[13:39] PeterThoeny: we can spend may be 10 minutes on requirements
[13:39] PeterThoeny: actual changes to the change proposal can be taken offline
[13:39] Lavr: A problem with the current implementation is that it works as a wish list for users. You can wish all you want but nothing is done unless someone is committed to do it.
[13:40] PeterThoeny: good point
[13:40] Lavr: The issue we address are the requests where someone IS committed to do it - but needs approval from the community.
[13:40] PeterThoeny: that possibly can be addressed by a state?
[13:41] Lavr: Could be. The form must contain a status that says that the feature implementation has an owner that has committed to do it. And the name of the owner.
[13:41] Flenser: wishlists should be confinded to BasicForm+BrainstormingIdea
[13:41] PeterThoeny: lets see if we can compile the requirements
[13:42] PeterThoeny: - way to track owner (make committment visible)
[13:42] Flenser: we got rid of that the last time we revised the form
[13:42] Lavr: And we need a field the "customer advocate" can set so you can make a search for topics that needs discussed at release meeting. Can be a state also
[13:42] PeterThoeny: - track "concerns": raise, investigate, resolved
[13:44] *** ArthurClemens has joined #twiki_edinburgh.
[13:44] PeterThoeny: lets divert a bit: the bugs web works nicely, i think due to its simplicity
[13:44] Flenser: should that be confined to ChangeProposals? you could have BasicForm topics with classifications of TWikiDevDoc, TWikiDevQuestion that you might also want to raise
[13:44] ArthurClemens: hi, I forgot about the meeting
[13:44] PeterThoeny: i think if we simplify the change proposal tracking we get a good acceptance
[13:44] PeterThoeny: hi arthur
[13:44] Lavr: Hi Arthur.
[13:44] *** Soronthar has joined #twiki_edinburgh.
[13:45] Flenser: raising topics for the meeting could be done with a tag
[13:45] PeterThoeny: hi rafael
[13:45] ArthurClemens: (so I am not the last person joining ;)
[13:45] ArthurClemens: hi raf
[13:45] PeterThoeny: we are disussing the requirements for the change proposals in the codev web, supporting the new process
[13:45] Soronthar: Hi all
[13:45] Lavr: Yes. Simplifying. And we need to decide what to do with the 258 proposals already there that are rotting. It is not realistic to think anyone will run through them in any near future.
[13:46] PeterThoeny: (Link: http://twiki.org/cgi-bin/view/Codev/TWikiRelease04x01Process)http://twiki.org/cgi-bin/view/Codev/TWikiRelease04x01Process
[13:46] PeterThoeny: and (Link: http://twiki.org/cgi-bin/view/Codev/ChangeProposal)http://twiki.org/cgi-bin/view/Codev/ChangeProposal
[13:46] Flenser: unless you want it to appear in WebChanges, in which case a WikiBadge would do, although I don't see the need for that
[13:46] *** Soronthar has signed off IRC (Read error: 104 (Connection reset by peer)).
[13:46] HaraldJoerg: Lavr: Correct.  That's the problem I have with discussing the process.
[13:47] *** Soronthar has joined #twiki_edinburgh.
[13:47] PeterThoeny: on existing proposals: this can be solved with a reclassification to new "parked" or existing "needs rethink"
[13:47] HaraldJoerg: Flenser: You wrote that the "owner" field has been removed from the form.  What was the reason?
[13:47] PeterThoeny: easy to do with global search & repalce
[13:47] Soronthar: My firefox is crashing on nearly every page on t.o
[13:47] PeterThoeny: those who wish to pick up a feature can reclassify it
[13:48] HaraldJoerg: I would prefer to discuss only proposals which do have an owner, and mark all the rest as "parked"
[13:48] Lavr: Could be. I just want to make sure that it is easy for Steffen and I to only see the proposals that have a committed developers that wants acceptance to go ahead.
[13:48] Flenser: HaraldJoerg:  one of the reasons the owner field was removed was that it was felt it was a barrier to others stepping in and helping
[13:49] HaraldJoerg: I think that has backfired
[13:49] PeterThoeny: i think an owner reflects commitment
[13:49] HaraldJoerg: IMHO others are more likely to step in if they know whether or not they are stepping on one's turf
[13:50] HaraldJoerg: ...or to see that they can help with a small contribution without having to carry the whole load of a topic
[13:50] PeterThoeny: and people are more likely to add notes if they see a chance of making it into an implemented feature
[13:50] Soronthar: Call it "Champion", not "Owner". 
[13:51] PeterThoeny: or "committer"?
[13:51] Soronthar: Yes. That. Something that reflects that "He's the one doing the work"
[13:51] Soronthar: not "this is HIS feature"
[13:52] PeterThoeny: yes, good point
[13:52] Flenser: does commiter imply that they make all the svn commits?
[13:52] HaraldJoerg: I'd also allow someone to be the owner if he's the one to motivate others to code stuff
[13:53] HaraldJoerg: Well written requirements can give "ownership" of a proposal without needing to code
[13:54] PeterThoeny: any other requirements for change proposal changes?
[13:54] Soronthar: what is the topic again? ChangeProposal?
[13:54] Flenser: that's the documentation topic for ChangeProposalForm 
[13:54] PeterThoeny: yes, in regards to new process
[13:55] Lavr: Remember also that the old process also was used for small fixes for which Bugs is used now. The Codev twiki app is for new features, spec changes, and similar. The things that require a community decision (which can be silence = accepted). An uncommitted feature request from a user does not get accepted from being ignored. It will not be picked up by the "customer advocate" role unless someone says "I will do it".
[13:56] Soronthar: we need an "UnderReview" state
[13:57] Flenser: what does that imply?
[13:57] Soronthar: that is under review for fitness
[13:57] PeterThoeny: actually, someone can bring a proposal and wait for two weeks if there are any concerns
[13:57] PeterThoeny: that is one state
[13:57] PeterThoeny: if someone raises a concern, that is another state
[13:58] HaraldJoerg: UnderReview is UnderInvestigation, isn't it?
[13:58] PeterThoeny: if no concern, it is accepeted after the grace period
[13:58] PeterThoeny: that is the third state
[13:58] Soronthar: I don't see it like that.
[13:58] Flenser: how would it fit into the UnderInvestigation -> ConsensusReached -> UnderConstruction workflow? see the ChangeProposal topic for definitions
[13:58] Soronthar: because I expect that if I have a fully-formed patch ready for merge, the feature is not "under investigation
[13:58] Soronthar: UnderInvestigation -> ConsensusReached -> UnderConstruction -> UnderReview->ReadyForMerge
[13:59] Lavr: Once the proposal is accepted - there is no need for more states. Work continues on Bugs.
[13:59] Soronthar: the latest sample was the =configure= rewrite from CDot and the FnTags from Meredith. They where "built" and "Reviews"
[13:59] HaraldJoerg: Soronthar: I'd prefer to do as much review as possible *before* the patch is done.
[14:00] Flenser: I think the ReadyForMerge state is the review state
[14:00] Soronthar: review of the "spec" and the idea, yes. I agree on that
[14:00] Lavr: The idea is that people can get an acceptance of the feature BEFORE spending time coding the feature.
[14:00] PeterThoeny: yes
[14:01] HaraldJoerg: I'd like to get pointed to e.g. changes in TWiki behaviour by the Codev topic, and not by wading through the code, or by beta testing
[14:01] PeterThoeny: actually, both happens: code ready or not ready at the time a proposal is done
[14:02] PeterThoeny: possibly decouple state of code readiness and handling concerns?
[14:03] Lavr: I see two sources of these Feature Proposal topics.    User that makes a wish, or developer that wants to add a feature. And I am afraid we drown is the former. There are more wishes than resources to do them.
[14:03] PeterThoeny: what i would like to see is a report that shows all pending change proposals for edinburgh, with an indication of the concerns
[14:03] Lavr: in the former.
[14:04] Flenser: if there are concerns then code readyness is irrelevant, just track the spec/concerns, not the code 
[14:04] PeterThoeny: kenneth: wishes and commited change proposals can be distinguished by the committer field
[14:05] Lavr: Yes. It just needs to be clear that the person that submits the proposal should not fill out this committer field. And the word "committer" may not be very clear on this.
[14:05] Soronthar: hmm.. we're talking different things: you're talking more about "consensun on the IDEA" status, and I was talking about "The code can go into SVN" status. My mistake. I agree with the workflow for the status of the idea.
[14:07] PeterThoeny: another idea: add a BugsTracking field
[14:07] Lavr: Yes. If we start reviewing code before committing it to SVN we drown the developers in red tape. A bad commit can and will be reverted. SVN makes that easy so no danger anyone screws up everything.
[14:07] PeterThoeny: if empty, it means no committer, e.g. wish
[14:07] PeterThoeny: if bugs item is listed it means it is tracked
[14:07] Flenser: PeterThoeny: do you mean a field for listing releated bugs?
[14:07] Lavr: You would not open a Bugs item before the proposal is accepted in my view.
[14:08] HaraldJoerg: The bugs item bears the danger that a topic is discussed in both bugs and Codev webs
[14:08] Flenser: actually it makes it less likely
[14:09] PeterThoeny: a change proposal needs to be tracked in one or more bugs items once the svn work starts
[14:09] Flenser: because you can more easily see the bugs topics so you can comment on them
[14:10] HaraldJoerg: Flenser: I've made a different experience with Item2582 vs. OrganizeTWikiVariables
[14:11] Lavr: A reference to Bugs is a good idea. Many proposals rise from a bugs item so the reference is good. But we cannot use the Bugs field to determine if a developer is driving it.
[14:11] PeterThoeny: harald: this can be addressed by adding links both in directions
[14:12] PeterThoeny: "adding links in both directions"
[14:12] HaraldJoerg: That topic had links in both directions.  
[14:13] Flenser: not in a location where people were used to looking
[14:13] HaraldJoerg: The weakness we currently have in the process is that discussion doesn't start in Codev before a SVN commit is done
[14:14] PeterThoeny: that point is addressed by the new process
[14:15] PeterThoeny: ok, i think we have enough brainstorming material
[14:15] PeterThoeny: who is going to work on the changes?
[14:15] Flenser: I can
[14:15] PeterThoeny: sam you did a nice job in the past
[14:15] PeterThoeny: great!
[14:16] PeterThoeny: sam, any burning questions before we move on?
[14:16] PeterThoeny: time: +75 min
[14:17] PeterThoeny: if not, lets move on
[14:17] PeterThoeny: ---++  4. Profiling framework for TWiki
[14:18] PeterThoeny: Desired outcome: Try to define roadmap for easy to use profiling tool
[14:18] PeterThoeny: harald, the floor is yours
[14:18] HaraldJoerg: Yeah - another example of "no discussion in Codev"
[14:19] PeterThoeny: (Link: http://twiki.org/cgi-bin/view/Codev/BenchmarkFramework)http://twiki.org/cgi-bin/view/Codev/BenchmarkFramework
[14:19] PeterThoeny: hmm, last comment on 19 Jul 2006
[14:20] HaraldJoerg: I've read your requirements, Peter, but that's not a short term agenda.
[14:20] PeterThoeny: harald, could you summarize the current state, and what you'd like to see next?
[14:20] HaraldJoerg: And this came immediately after the last meeting where we discussed it.
[14:21] HaraldJoerg: Recently (r11384) I have committed what I think is the only change which is needed in the TWiki core
[14:21] PeterThoeny: could you explain?
[14:22] HaraldJoerg: Most of the hack I've demonstrated in the last meeting should be done in a Contrib
[14:23] HaraldJoerg: It is using a separate bin/profile driver
[14:23] HaraldJoerg: But what was needed was a way to modify TWiki for just one request, i.e. without writing any configuration files to disk
[14:23] PeterThoeny: i think that is a sensible approach, contrib just for developers (out of the way for users)
[14:24] PeterThoeny: do you see any actions items for us?
[14:24] PeterThoeny: e.g. anything we can help?
[14:25] HaraldJoerg: Knowing which parameters you'd like to provide would be helpful
[14:26] PeterThoeny: where is the latest spec documented?
[14:26] HaraldJoerg: There isn't even a spec right now.
[14:27] PeterThoeny: how about documenting at the top of (Link: http://twiki.org/cgi-bin/view/Codev/BenchmarkFramework)http://twiki.org/cgi-bin/view/Codev/BenchmarkFramework ?
[14:28] HaraldJoerg: What would you like to see?
[14:28] PeterThoeny: the how to is entirely up to you, here is the "what" as far as i am concerned:
[14:28] HaraldJoerg: The (more or less) current form is at (Link: http://munich.pm.org/cgi-bin/view/Benchmarks/WebHome,)http://munich.pm.org/cgi-bin/view/Benchmarks/WebHome, but I *think* it isn't sufficient
[14:29] PeterThoeny: an easy way for developers to define areas to test performance, run benchmark before and after a change, and compare benchmarks
[14:30] Lavr: Access Denied
[14:31] Lavr: Access check on Benchmarks.Benchmarks_WebHome_0 failed. Action "change": access not allowed on web
[14:31] Lavr: I just added my wish to (Link: http://twiki.org/cgi-bin/view/Codev/BenchmarkFramework)http://twiki.org/cgi-bin/view/Codev/BenchmarkFramework
[14:31] HaraldJoerg: Lavr: You aren't allowed to *run* benchmarks on that web, that's correct.
[14:32] Lavr: I first tried Main.
[14:32] HaraldJoerg: This isn't yet a public TWiki, 'cause I don't want to spend the time to check for abuse
[14:32] HaraldJoerg: It is just the only TWiki where I can implement showcases
[14:33] Lavr: Sandbox does not work either. What works? I would like to see what is shows on any topic.
[14:33] PeterThoeny: harald: could you update the Codev.BenchmarkFramework with what you have so that we can provide better feedback?
[14:34] PeterThoeny: +95 min
[14:34] PeterThoeny: i am affraid i need to bail out of the meeting
[14:34] Lavr: Mee too. 
[14:34] Lavr: Me. Cannot spell.
[14:35] HaraldJoerg: If only I'd have some confidence that someone is going to *provide* feedback.  This has been requested on several release meetings, but no input was proveded (not even the requirement to provide a better spec)
[14:35] PeterThoeny: harald, if you can provide specific input what kind of feedback/help you are looking for in Codev.BenchmarkFramework that would be great
[14:36] PeterThoeny: chicken and egg :-)
[14:36] Lavr: I just added a "soft" wish. In one line. What we need is a tool that tells us as many details as possible on "What does TWiki do while it calculates the page that was requested?". Not just another benchmark tool to see changes.
[14:36] HaraldJoerg: Ok, I'll try to refactor...
[14:37] PeterThoeny: ok, nice meeting with small group
[14:37] PeterThoeny: ttyl...
[14:37] HaraldJoerg: Lavr: Like a sequential tree of subroutines called? That makes some 10000 lines per request (BTDT)
[14:37] Lavr: There are so many "religious" oppinions that different developers and users give on what should be changed to speed up TWiki. But we have lacked hard evidence to say that this feature, or this part of the code spends all the time.
[14:39] Lavr: When soneone ran some detailed profiling on Motion we also got a lot of data. But some functions/features stood out as time stealers and by optimizing those top 10 we gained a lot of performance.'
[14:40] HaraldJoerg: Let me show an example of what I have in mind: Look at (Link: http://munich.pm.org/cgi-bin/view/Benchmarks/Tools_MiniAHAH_5)http://munich.pm.org/cgi-bin/view/Benchmarks/Tools_MiniAHAH_5 and (Link: http://munich.pm.org/cgi-bin/view/Benchmarks/Tools_MiniAHAH_6.)http://munich.pm.org/cgi-bin/view/Benchmarks/Tools_MiniAHAH_6.  The only difference is that one is using plain, the other pattern skin.  So you can see what, and where, pattern skin is burning its cycles.
[14:40] HaraldJoerg: But "skin" is only one, and a rather trivial example.
[14:41] HaraldJoerg: I see Peter is right, maybe I'd have to simply list some things which I would like to run for comparisons.
[14:41] HaraldJoerg: (and of course, it would be nice to provide a list of setups and have the benchmark tools immediately calculate the differences)
[14:44] HaraldJoerg: ...no, correction: (Link: http://munich.pm.org/cgi-bin/view/Benchmarks/Tools_MiniAHAH_4)http://munich.pm.org/cgi-bin/view/Benchmarks/Tools_MiniAHAH_4 is running pattern skin.
[14:44] HaraldJoerg: _5 is plain, and _6 is text (i.e. no template processing at all)
[14:45] Lavr: TWiki::Render::getRenderedVersion 15%   Does in itself not say much. - So what happens in this would be a natural question. Why is a function called 3 times and not 1 is another. Why does a function get called 500 times? And could part of this function be cached so more calls are faster? etc etc.
[14:46] HaraldJoerg: Lavr: Exactly.
[14:47] HaraldJoerg: There's a line-oriented module Devel::SmallProf, but it creates megabytes of data, and there's the calling hierarchy, which creates 15000 lines.
[14:48] HaraldJoerg: I think that the most promising step, after seeing that 15%, is to have a look at the code.
[14:48] HaraldJoerg: To learn how much it would be quicker if a function were cached, you need to implement the caching code anyway.
[14:49] HaraldJoerg: So I'd like to say "rerun the benchmark, but for this time pick Render.pm from another directory".
[14:49] Lavr: Yes. But what the profile does is guide you to work on the parts of the code that gives pay back in form of performance.
[14:50] ArthurClemens: I need to get some sleep before tomorrow. Good luck with the rest of the meeting.
[14:50] *** ArthurClemens has left #twiki_edinburgh.
[14:50] HaraldJoerg: ... and it could hint to "try again without localisation"
[14:51] HaraldJoerg: ... and it does give some hints of how much could be improved with mod_perl (just sum up all the BEGIN blocks)
[14:53] Lavr: Yes. I think the overall driver is - what is TWiki spending time on?  more than being very accurate and very reproduceable. TWiki today is slow even with almost empty topics with no advanced features. So there are some basics that consume time and it would be very usefull to learn more.
[14:53] Lavr: That could also mean making some analysis tool to dig out info from a megabyte of profiling data from a single run of view.
[14:54] *** Soronthar has signed off IRC ("Chatzilla 0.9.69 [Firefox 1.0.7/20050915]").
[14:55] Lavr: I will also hit the pillow now. I need sleep. Good night. I will add the few actions to the minutes tomorrow.
[14:56] HaraldJoerg: Ok, let's continue in Codev....  or in two weeks, whichever comes first :-)