Category: Mozilla

Categories
Mozilla Technology

Highlight Warnings in Make

Curtis just gave me this incredibly handy piece of code that higlights errors and warnings in make output. Now, when I’m building, all the warnings are highlighted in yellow, and the errors in red. Just put the following in your bash profile script:

make()
{
  pathpat="(/[^/]*)+:[0-9]+"
  ccred=$(echo -e "\033[0;31m")
  ccyellow=$(echo -e "\033[0;33m")
  ccend=$(echo -e "\033[0m")
  /usr/bin/make "$@" 2>&1 | sed -E -e "/[Ee]rror[: ]/ s%$pathpat%$ccred&$ccend%g" -e "/[Ww]arning[: ]/ s%$pathpat%$ccyellow&$ccend%g"
  return ${PIPESTATUS[0]}
}

Of course, improvements and more ideas welcome! Thanks goes to Curtis for this!

Categories
Mozilla

Performance Regressions are Painful

I think it is a well known fact that performance regressions are really painful. They cause pain on more than one front too! You have users who have a less responsive application, drivers who have to figure out who and what caused the regression, and developers who have to backout or come up with a fix for the regression.

Until recently, we only had a heavy handed tool (the graph server) that is slow and painful to use. Recently, Johnathan has revamped his performance dashboard which is a very quick and easy way for people to see the current status of some of the more important performance graphs (it’s also easy to hack on!). This has made spotting a regression much easier and faster, which great increases the odds of the offending change(s) being backed out. The longer a performance bug is left in the tree, the harder it becomes to do a straight backout.

Today I decided I was going to spend the day eliminating the rest of our open performance bugs (or make sure they had blocking requested for the current release). However, I was amazed at how many old performance bugs we had open that hadn’t been touched in six months or more. I probably closed about 20 bugs as INCOMPLETE since there was virtually no way we were going to be able fix those bugs anymore. One bug I was actually able to mark as FIXED, and there were a few more that were recent regressions that I posted comments on to make sure people were still working on.

This made me realize that we have a serious problem though. We currently have no way for people who care about performance regressions to easily be aware of new bugs filed. To help this, I went ahead and filed bug 467170 which will allow folks to add an e-mail address to the cc list of all performance regression bugs so the folks who care about this can watch the address and get mail about these issues. Once bug 464609 gets resolved the sheriffs will also have a place to bring these issues up so the next sheriff is aware of what is going on as well.

I think we are starting to move in the right direction when it comes to performance monitoring, but I think we also have a long ways to go. Remember kids, only you can help stop performance regressions.

Categories
Mozilla Personal Technology

I’m in a podcast!

A little while ago I got interviewed by Anthony Bryan from the metalink project. I feel sorry for him because it took me several long months to actually get the time to sit down and talk to him. Anyway, you can check out the podcast here. They used an old facebook photo of mine, so, uh, pardon the odd image of me. I figured it could be worse though.

It’s worth a listen though. I talk about some of the features of the new download manager (old news now, but he ask for this interview a while ago…), how I got involved with the Mozilla project, and a few other interesting tidbits including what I’ve currently been working on. There is other interesting things in there too!

Categories
Mozilla

DTrace Awesomeness

Yesterday dietrich was telling me he was seeing a lot of writes to places.sqlite and places.sqlite-journal. I wanted to get good, hard data to see what was writing, and how often we were doing it. I figured this was a good option for DTrace, but I've had mixed experiences with it in the past. I first turned to Instruments on OS X, but that can't give you stacks for calls, so I had to dump it.

I talked to dolske, who happens to be the resident DTrace expert around here. With his help, I was able to put together this little D script to track writes to the files in question, and give me user stack traces so we know who is writing and when. With this, we've figured out what was writing, and are working on how to make it write less as we speak.

DTrace really is an awesome tool, even if it can be a bit awkward to use from time to time.

Categories
Mozilla

Asynchronous Storage API Take 2

It’s been a bit more than three months since I wrote about the asynchronous storage API landing in mozilla-central. As far as I know, there are still no consumers of it in mozilla-central, but I do think that the Thunderbird folks are using it (they’ve been filing several bugs about it). We were looking at using it in places to help with the fsync issues we’ve been working with, and noticed a major flaw to the API. You cannot perform more than one statement at a time in a specific order asynchronously without jumping through a number of hoops that happen to also be on fire. Enter bug 458811. That landed on Monday, so now it’s easy to do – just call mozIStorageConnection::executeAsync and pass it an array of bound statements. Hope others find this just as useful as we did!