StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
primarykey
Id
3277984
data
AcceptedAnswerId
0
AnswerCount
0
ClosedDate
CommentCount
1
CommunityOwnedDate
CreationDate
2010-07-19T01:38:08.580
FavoriteCount
0
LastActivityDate
2010-07-19T01:38:08.580
LastEditDate
LastEditorUserId
0
OwnerUserId
20938
ParentId
3277239
PostTypeId
2
Score
5
ViewCount
0
LastEditorDisplayName
text
Body
<p>You're processing each file five times, so the first thing you should do (as Paul Sanwald said) is try to reduce that number by combining your regexes together. I would also avoid using reluctant quantifiers, which are designed for convenience at the expense of efficiency. Consider this regex:</p> <pre><code><script.*?</script> </code></pre> <p>Each time the <code>.</code> goes to consume another character, it first has to make sure <code></script></code> won't match at that spot. It's almost like doing a negative lookahead at every position:</p> <pre><code><script(?:(?!</script>).)*</script> </code></pre> <p>But we know there's no point doing the lookahead if the next character is anything but <code><</code>, and we can tailor the regex accordingly:</p> <pre><code><script[^<]*(?:<(?!/script>)[^<]*)*</script> </code></pre> <p>When I test them in RegexBuddy with this target string:</p> <pre><code><script type="text/javascript">var imagePath='http://sstatic.net/stackoverflow/img/';</script> </code></pre> <p>...the reluctant regex takes 173 steps to make the match, while the tailored regex takes only 28.</p> <p>Combining your first three regexes into one yields this beast:</p> <pre><code><(?:(script|style)[^<]*(?:<(?!/\1)[^<]*)*</\1>|[!/]?[a-zA-Z-]+[^<>]*>) </code></pre> <p>You might want to zap the <code><HEAD></code> element while you're at it (i.e., <code>(script|style|head)</code>).</p> <p>I don't know what you're doing with the fourth regex, for character entities--are you just deleting those, too? I'm guessing the fifth regex has to be run separately, since some of the whitespace it's cleaning up is generated by the earlier steps. But try it with the first three regexes combined and see how much difference it makes. That should tell you if it's worth going forward with this approach.</p>
Tags
Title
singulars
PostAcceptedAnswerId
1. This table or related slice is empty.
PostParentId
1. POSpeeding up regular expressions in Python
  singulars
  PostTypePostTypeId
  PTQuestion
PostTypePostTypeId
1. PTAnswer
UserLastEditorUserId
1. This table or related slice is empty.
UserOwnerUserId
1. USAlan Moore
plurals
PostLinksPostIdRelatedPostId
1. This table or related slice is empty.
PostLinksRelatedPostIdPostId
1. This table or related slice is empty.
PostsAcceptedAnswerId
1. This table or related slice is empty.
PostsParentIdCreationDate
1. This table or related slice is empty.
VotesPostIdCreationDate
1. VO
  singulars
  PostPostId
  PO
  UserUserId
  This table or related slice is empty.
  VoteTypeVoteTypeId
  VTUpMod
2. VO
  singulars
  PostPostId
  PO
  UserUserId
  This table or related slice is empty.
  VoteTypeVoteTypeId
  VTUpMod
3. VO
  singulars
  PostPostId
  PO
  UserUserId
  This table or related slice is empty.
  VoteTypeVoteTypeId
  VTUpMod
CommentsPostId
1. COThanks for the insight about reluctant quantifiers. Profiling did show that these are expensive! I will modify my regex.
  singulars
  PostPostId
  PO
  UserUserId
  USAbhi

Querying!

Guidance

A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.