Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

doc: reorganize benchmarking guide/readme, update test/README.md #11237

Closed
wants to merge 7 commits into from

Conversation

joyeecheung
Copy link
Member

@joyeecheung joyeecheung commented Feb 8, 2017

The current benchmark/README.md is in fact a guide on how to run and write benchmarks, this PR moves it to doc/guides (where writing-tests.md is) and create another README.md that explains the directory layout/common API (like what test/README.md does). This should make it easier for new contributors to find out what to do when they need to provide a benchmark.

Also updates the test/README.md to add a link to the testing guide.

Fixes: #11190

Checklist
  • make -j4 test (UNIX), or vcbuild test (Windows) passes
  • documentation is changed or added
  • commit message follows commit guidelines
Affected core subsystem(s)

doc

@joyeecheung joyeecheung changed the title doc: doc: move benchmark/README.md to doc/guides, update test/README.md Feb 8, 2017
@joyeecheung
Copy link
Member Author

Would like some feedback from @AndreasMadsen on the new benchmark/README.md

@joyeecheung joyeecheung changed the title doc: move benchmark/README.md to doc/guides, update test/README.md doc: reorganize benchmarking guide/readme, update test/README.md Feb 8, 2017
@joyeecheung joyeecheung added doc Issues and PRs related to the documentations. benchmark Issues and PRs related to the benchmark subsystem. test Issues and PRs related to the tests. labels Feb 8, 2017
@AndreasMadsen
Copy link
Member

AndreasMadsen commented Feb 8, 2017

I'm not sure I agree with the hole guide concept as I think it is too hidden, but looking besides that:

  • please compress the Benchmark Directories section, perhaps use a <dl> list or a table (I would say the same for test/README.md, but that may be out of scope).
  • Do we need Other Top-level files, the test/README.md doc doesn't have this.

@joyeecheung
Copy link
Member Author

@AndreasMadsen Thanks for the feedback. I agree the guides are a little bit hidden at the moment, but as we put more documents there hopefully they can get more traction.

About the directories, if we make the same changes to test/README.md then a table would be better since they have Run on CI info. That can also make it easier to read. cc @Trott considering the history of that file.

The Other Top-level files could give info to people who want to improve the tooling, that probably doesn't apply to test/README.md since the testing tools are in tools, not test.

* `_cli.R`: parses the command line arguments passed to `compare.R`
* `_http-benchmarkers.js`: selects and runs external tools for benchmarking
the `http` subsystem.
* `common.js`: see [Common API]((#common-api)).
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should it be only one pair of parentheses?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, good catch!

Copy link
Member

@jasnell jasnell left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Almost there

writing JavaScript run by the built-in JavaScript engine.

For a detailed guide on how to write and run benchmarks in this
directory, see [the guide on benchmarks](../doc/guides/writing-and-running-benchmarks.md).

## Table of Content
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I know this was already there but s/Content/Contents


## Benchmark Directories

### arrays
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Having these as a table may be more concise. Separate headers doesn't seem necessary

```
Force V8 to optimize the function with the native function
`%OptimizeFunctionOnNextCall()` and return the optimization status
after that.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A mention about the (common.v8ForceOptimization()](https://github.com/nodejs/node/blob/master/benchmark/common.js#L233) utility method would be good here.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Uh, well, this is actually the documentation of that method :S


## Prerequisites

Most of the HTTP benchmarks require a benchmarker to be installed, this can be
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would recommend putting these under sub-headings.. e.g. ### HTTP Benchmark Requirements, etc


### Comparing node versions

To compare the effect of a new node version use the `compare.js` tool. This
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In general throughout this doc, since edits are being made anyway, please s/node/Node.js/g

test/README.md Outdated
On how to run tests in this direcotry, see
[the contributing guide](../CONTRIBUTING.md#step-5-test).

## Table of Content
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

s/Content/Contents


It is used to prevent the benchmark from getting disrupted
by the optimizer kicking in halfway through. However, this could result in a
less effective optimization, so it should be used with caution.
Copy link
Member

@TimothyGu TimothyGu Feb 12, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The actual signature is v8ForceOptimization(method, ...args), where args are passed to method.apply. Also of note is that method is executed with this set to null. You might also want to explain why it can "result in a less effective optimization."

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the reasons for a less effective optimization are probably too many to explain here(no proper inlining because the profiler doesn't know the functions calls inside are hot, no proper type feedback, possible deopt, etc)..probably better left for another PR to update the guide instead of a readme.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A general guide would be to grep deps/v8/test with OptimizeFunctionOnNextCall to see how it's used though.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmmm..also this doesn't actually optimize the monomorphic pattern method(...args) if the method has been called with other context/args during the startup, it could be polymorphic or even megamorphic.

Copy link
Member Author

@joyeecheung joyeecheung Feb 12, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

..so documenting the null and ..args part could be misleading, I am inclined to stay a little bit vague here, if we need to be precise probably it would be best understood by reading its source code.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The signature should be corrected though :D

@joyeecheung
Copy link
Member Author

@jasnell @TimothyGu @vsemozhetbyt Thanks for the reviews, updated, PTAL.

@vsemozhetbyt
Copy link
Contributor

vsemozhetbyt commented Feb 12, 2017

@joyeecheung I am not sure if this is a subject for this PR, but could the parameters of the compare.js be documented? I've recently added a benchmark to the dgram suite and I could not find a way to run just one benchmark file with compare.js in the guide. Currently, the "Comparing Node.js versions" chapter has only an example how to run a whole suite (and the whole dgram suite lasts in my machine ~ 6 hours). So maybe the --filter and other params from this fragment are worth to be documented for benchmark beginners.

@AndreasMadsen
Copy link
Member

@vsemozhetbyt My opinion is that this is a bit out of scope for this pull request. But you are right that it is missing, at the very least we should document how to print the help text. I would also like to consistently have a --help option. Do you want to make a pull request?

@vsemozhetbyt
Copy link
Contributor

@AndreasMadsen I am not so good in English, so I usually abstain from creating a non-js text in docs. Sorry for not to be helpful here.

@joyeecheung
Copy link
Member Author

@vsemozhetbyt @AndreasMadsen The current logic in _cli.js is to print the usage when process.argv.length < 3 i.e. when those scripts are run without command line arguments. I'll put this information in the guide for now, another PR describing the arguments in detail should be useful.

@AndreasMadsen
Copy link
Member

The current logic in _cli.js is to print the usage when process.argv.length < 3 i.e. when those scripts are run without command line arguments

I'm aware, but it is not the most intuitive way of getting the help text, it was mostly intended as an input validation. There is also the R scripts where one of them only prints if --help is provided (because it only takes optional arguments) and the other behaves likes the js scripts.

@joyeecheung
Copy link
Member Author

@AndreasMadsen Should we document the current behavior in this PR? I think it's probably better than nothing. If another PR implements --help it can update the guide(or I can rebase, whichever comes the first)

@AndreasMadsen
Copy link
Member

Should we document the current behavior in this PR? I think it's probably better than nothing. If another PR implements --help it can update the guide(or I can rebase, whichever comes the first)

I like the simple documentation as you have done it now. But as a principal one shouldn't need to look in the documentation in order to learn how to print the help text.

@joyeecheung
Copy link
Member Author

@jasnell @TimothyGu @vsemozhetbyt @AndreasMadsen Can I have a few LGTM please?

@AndreasMadsen
Copy link
Member

AndreasMadsen commented Feb 13, 2017

Do we prefer HTML tables or Markdown tables? Personally I find HTML tables easier to read than Markdown tables when there is a lot of text (markdown lines exceed 80 char).

@joyeecheung
Copy link
Member Author

I tried the markdown tables first but couldn't find a way to use linebreaks in them, some of the lines are a bit long so I just switched to HTML. I think markdown tables are easier to read when your cells tend to be small and just contain a few words, but not when you want to write actual sentences in them?

joyeecheung added a commit that referenced this pull request Feb 17, 2017
Since benchmark/README.md is in fact a guide on how to
write and run benchmarks, move it to doc/guides.

PR-URL: #11237
Fixes: #11190
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Andreas Madsen <amwebdk@gmail.com>
joyeecheung added a commit that referenced this pull request Feb 17, 2017
* Write a new benchmark/README.md describing the benchmark
  directory layout and common API.
* Fix the moved benchmarking guide accordingly, add tips about how
  to get the help text from the benchmarking tools.

PR-URL: #11237
Fixes: #11190
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Andreas Madsen <amwebdk@gmail.com>
joyeecheung added a commit that referenced this pull request Feb 17, 2017
* Add description about the test directory
* Add link to the test writing guide and the contributing guide
* Use table to describe the directory layout and CI info

PR-URL: #11237
Fixes: #11190
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Andreas Madsen <amwebdk@gmail.com>
@joyeecheung
Copy link
Member Author

joyeecheung commented Feb 17, 2017

Landed in f8ee197...736814e, thanks!

@joyeecheung joyeecheung deleted the guide-and-readme branch February 19, 2017 17:43
addaleax pushed a commit that referenced this pull request Feb 22, 2017
Since benchmark/README.md is in fact a guide on how to
write and run benchmarks, move it to doc/guides.

PR-URL: #11237
Fixes: #11190
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Andreas Madsen <amwebdk@gmail.com>
addaleax pushed a commit that referenced this pull request Feb 22, 2017
* Write a new benchmark/README.md describing the benchmark
  directory layout and common API.
* Fix the moved benchmarking guide accordingly, add tips about how
  to get the help text from the benchmarking tools.

PR-URL: #11237
Fixes: #11190
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Andreas Madsen <amwebdk@gmail.com>
addaleax pushed a commit that referenced this pull request Feb 22, 2017
* Add description about the test directory
* Add link to the test writing guide and the contributing guide
* Use table to describe the directory layout and CI info

PR-URL: #11237
Fixes: #11190
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Andreas Madsen <amwebdk@gmail.com>
@italoacasas italoacasas mentioned this pull request Feb 25, 2017
jasnell pushed a commit that referenced this pull request Mar 7, 2017
* Add description about the test directory
* Add link to the test writing guide and the contributing guide
* Use table to describe the directory layout and CI info

PR-URL: #11237
Fixes: #11190
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Andreas Madsen <amwebdk@gmail.com>
@jasnell
Copy link
Member

jasnell commented Mar 7, 2017

requires a backport PR to land on v4

@joyeecheung
Copy link
Member Author

Got some weird merge conflicts..looks like there are ancestor commits not yet backported.

@AndreasMadsen
Copy link
Member

The benchmark suite runner was rewritten in v7 and because of some issue reports it was decleared a major change. This should not be backported to v4 or v6.

MylesBorins pushed a commit that referenced this pull request Mar 9, 2017
* Add description about the test directory
* Add link to the test writing guide and the contributing guide
* Use table to describe the directory layout and CI info

PR-URL: #11237
Fixes: #11190
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Andreas Madsen <amwebdk@gmail.com>
@MylesBorins MylesBorins mentioned this pull request Mar 9, 2017
@joyeecheung joyeecheung mentioned this pull request Apr 19, 2017
2 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
benchmark Issues and PRs related to the benchmark subsystem. doc Issues and PRs related to the documentations. test Issues and PRs related to the tests.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants