Re: [Monotone-devel] Unnecessary performance hit on push?
On 1 okt 2005, at 5:03, Nathaniel Smith wrote: Just a guess, but what happens if you put a transaction guard around the whole chunk? (OS X has extra-paranoid disk-flushing stuff, that makes wrapping multiple writes into a single transaction _very_ important. I don't know why it would matter here, since naively it looks like we're just reading, but...) transaction_guard guard(app.db); do stuff guard.commit() The initial time stays roughly the same (bit longer seems), the second runs go from around 15 secs to 38secs. I dont think the direct problem is in monotone itself, even if run on an otherwise minimal system, the monotone process is basically doing nothing, cpu/mem wise. Gonna try to find with Shark (osx profiler app) what the system is actually doing. marcel -- Marcel van der Boom HS-Development BV -- http://www.hsdev.com So! webapplicatie framework -- http://make-it-so.info smime.p7s Description: S/MIME cryptographic signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] status --brief
On Fri, Sep 30, 2005 at 08:44:14PM -0700, Howard Spindel wrote: I find it a bit reassuring to get the non-brief status, especially when there is nothing to do and the brief status simply returns to the command prompt with no output. Ah, okay, actually I think that particular thing is a bug in --brief -- IMO it should print no changes if there are no changes, similar to what 'monotone diff' does. Does that change your opinion either way? -- Nathaniel -- ...All of this suggests that if we wished to find a modern-day model for British and American speech of the late eighteenth century, we could probably do no better than Yosemite Sam. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Unnecessary performance hit on push?
On Sat, Oct 01, 2005 at 10:00:30AM +0200, Marcel van der Boom wrote: I dont think the direct problem is in monotone itself, even if run on an otherwise minimal system, the monotone process is basically doing nothing, cpu/mem wise. Gonna try to find with Shark (osx profiler app) what the system is actually doing. Oh, sure, it's obviously waiting on IO. The question is what IO are we doing that takes so long, and how can we not do that :-). -- Nathaniel -- .i dei jitfa fanmo xatra ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Unnecessary performance hit on push?
On 1 okt 2005, at 11:35, Nathaniel Smith wrote: Oh, sure, it's obviously waiting on IO. The question is what IO are we doing that takes so long, and how can we not do that :-). I took a fresh copy of the database from the server. The problem completely disappears with that new db file (!?). It's still happening on the other file. I'm pretty sure the db is ok (monotone wise); db check returns fine. Suppose there would be the possibility of a stale lock file (not sure if sqlite/osx even does that, reading through os_unix.c in sqlite doesnt bring much optimism to the table either), could that be a cause? From running fs_usage on the mt process it just displays a read/ lseek during the whole time mt sits doing nothing. fs_usage also displays a 'W' in its output (from Waiting?) but i havent been able to figure out what that means. Although the new db copy workaround seems to solve my direct problem, i'm now too deep into it to give up and really would like to know what's causing this. marcel -- Marcel van der Boom HS-Development BV -- http://www.hsdev.com So! webapplicatie framework -- http://make-it-so.info smime.p7s Description: S/MIME cryptographic signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Unnecessary performance hit on push?
* Nathaniel Smith: Oh, sure, it's obviously waiting on IO. The question is what IO are we doing that takes so long, and how can we not do that :-). It's probably the effect of internal database fragmentation, coupled with file system fragementation: monotone.db: 8686 extents found, perfection would be 1 extent Running VACUUM seems to help quite a bit, defragmenting the file at the file system level doesn't make such a big difference. (But this is for reading the certs before pull. I didn't notice soon enough that this thread is about push performance.) ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] [ANNOUNCE] monotone 0.23
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The Source Mage GNU/Linux monotone package has been updated, thanks. :) - -sandalle - -- Eric Sandall | Source Mage GNU/Linux Developer [EMAIL PROTECTED] | http://www.sourcemage.org/ http://eric.sandall.us/ | SysAdmin @ Inst. Shock Physics @ WSU http://counter.li.org/ #196285 | http://www.shock.wsu.edu/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDPrCuHXt9dKjv3WERAsMoAJ9ll0a4hlE+ZSA0GbV6XvbptesWzACfXxZk hhpS7R1nxN7m1rtnMh3Cg2k= =pX2y -END PGP SIGNATURE- ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] status --brief
Nathaniel Smith [EMAIL PROTECTED] wrote: Ah, okay, actually I think that particular thing is a bug in --brief -- IMO it should print no changes if there are no changes, similar to what 'monotone diff' does. Hmm... It all depends upon which philosophies you follow for UI design. Are you trying to follow UNIX design philosophy, succeed silently or the Windows philosophy, more of a succeed or fail, just do it loudly. no changes would be an example of succeeding loudly. ;-) Does that change your opinion either way? Because monotone status always returns zero (0), having no changes for an output is probably the only way to get meaning out of the command for use in scripts, although the lack of output has meaning in and of itself. Instead of outputting no changes, I would like to see some thought given to the return values for monotone. I'm partial to brief/quiet modes as a default setting and using verbose modes as an option. Perhaps provide a global lua hook to specify the default in monotonerc? ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Just a simple, Thanks!
Just wanted to send you all a simple Thanks! for providing such a great tool! The more I use monotone, the more I like it. There is always an adjustment period, during which time I should have probably kept my mouth shut on the development list. ;-) Strike my suggestion for INI-style output, for example; I like what monotone currently uses. One thing I wish was easier to do was fix mistakes regarding commits to branches, when I forget to add a new '-b NEWBRANCH' option, for example. Monotone does the right thing and happily commits to the current branch. I realize I could add a cert named branch with the NEWBRANCH value, but then the revision belongs to two branches, and I'm not sure what type of chaos that might cause for Monotone. I've tried deleting the old branch cert from my local repository (no contact w/an outside repository just yet), but then monotone status complains that the revision has no ancestors. :-P. So, obviously, I have stuff to learn about how monotone handles these things. Since I'm not too many revisions in (just checking in upstream tarballs and patches), I could always recreate it (a bit more carefully this time). Any concensus on what people like to name version-based branches? RFQDN.project-VERSION or RFQDN.project.VERSION? Where VERSION = alphanumerics and '_'? (I write this as my 12 month old son has discovered that playing on the stairs is Great Fun! At least he's only two steps up, at this point. I'll start worrying when he crawls up past the bumps and bruises potential energy step, which I estimate to be step three...) Anyway, thanks again, folks! Great tool! -- Chad Walstrom [EMAIL PROTECTED] http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
